How to Install Newer JVM for IS

How do I go about installing a newer JVM so that IS will use it? It comes with 1.3.0, but I have heard from some webMethods folks that IS will perform better using 1.3.1 or 1.4.x.

I’ve tried installing the full J2SE SDK and then copying the bin and lib directories out of the jre directory into the \webMethods\IntegrationServer\jvm directory, but that doesn’t work.

Any ideas?

Have a peak at your runserver.bat

The full path to your runtime exe should show up there. Make sure your new runtime exe is copied here.

“C:\Program Files\webMethods\IntegrationServer4\jvm\bin\java.exe”

Before moving to higher versions of jdk, check with webMethods Support about the compatibility. TN4.6 may not work with jdk1.4.x. We faced a problem with TN conecting to database (OS -win2000, DB - Oracle) when jdk1.4.x was installed. It was throwing some exceptions related to Connection classes, while trying to conect to TN using TN Console. Swtiched back to jdk1.3.1 and the issue was solved.

This is the procedure I have used many times.
Install the new jdk/jre into a directory (E.G. jdk1.3.1_08 or jre1.3.1_08) on a computer of your choice. It does not need to be the computer that the Integration Server is running on.
Copy the entire jdk1.3.1_08/jre1.3.1_08 directory to the destination computer.

The next part involves a choice. The key though, is that your server.bat file must point to the new jdk/jre directory. look for a line like: SET JAVA_ROOT=e:\webMethods\IS46\jvm in server.bat. (the line will reflect where you installed IS, in my case I installed into e:\webMethods\IS46)

Either modify that line in server.bat to point to your new jdk/jre directory (E.G. SET JAVA_ROOT=e:\jdk1.3.1_08) or copy the new jdk/jre into your \webMethods\IntegrationServer directory as jvm ( rename the existing \webMethods\IntegrationServer\jvm directory first). My preference is the second method.

The batch file, server.bat builds the batch file runserver.bat. One way to make sure your IS is using the new jdk/jre is to rename/delete runserver.bat and start IS. A new runserver.bat file should appear. If not, the most likely cause is a typo in the mod to server.bat. You also can always turn “echo on” in server.bat and run it from a cmd prompt to see where it is failing.

webMethods 601 GA seems too have shipped with both both jvm 1.3 & 1.4 (in installdir\jvm\win.sun13 and installdir\jvm\win.sun14).

A while ago I attempted a run using this JVM 1.4 (by editing server.bat), but this resulted in the server dying with log showing:

2003-03-24 17:48:48 GMT [ISS.0025.0023C] Audit Log Manager started
2003-03-24 17:48:49 GMT [ISS.0025.0021C] ACL Manager started
2003-03-24 17:48:49 GMT [ISS.0025.0008C] State Manager started Error instantiating SecureRandom: iaik.sec
urity.random.RandomException: Could not get AES algorithm!

Has anybody else managed to run webMethods 6 with this JVM 1.4 or would I have to install yet ANOTHER JVM 1.4 ?

Currently, the product is not certified to run the 1.4.x version of the JVM. This is in the release docs.

I have several clients who are running 6.01. One client had the IBM JRE 1.3.0 installed (have no idea how or why.) I ramped the system over to the Sun JDK 1.3.1_07 for Windows.

In addition to the switch of JVMs as noted in previous posts, there are a couple of tuning tips that you should try out:

  1. Make the memory settings the same:
    set JAVA_MIN_MEM=256M
    set JAVA_MAX_MEM=256M

This will allocate all the available memory upfront and in the long run, you will be happier with the performance.

  1. Set a “-server” switch in the server.bat file as well:


This is further down in the server.bat file. THIS WILL NOT WORK FOR THE IBM JRE and may not work with any JRE. I always use the JDK so cannot note if it will run correctly.

A quick way to test which JVM you are using, is to click on the “ABOUT” link in the Admin console. It will provide you with the path to the JRE/JDK along with your entire path with all jars, etc.

In the line noted above, set JAVA_RUN=%JAVA_EXE% -server %JAVA_MEMSET%
if you replace the “-server” switch with “-version” and then run the server.bat at console (WINDOWS), it will display the version of the JVM and then exit. You will type:

server.bat -log none -debug 6

The window will display the Java Virtual Machine info. Hope this helps.

  1. Create a java service called “runGarbage”. Make it in a package/interface that you plan to keep around for some time.

In the Java service, type in this line:


That’s it. After you save it, create a scheduler to run repeatedly every 2 - 5 minutes. Look at the memory meter, it will flatten out over time. This has a higher priority then the gcMins setting in the server.cnf file.


i simply replace everything inside the webMethods\IntegrationServer\jvm with the jdk131\ stuffs and it works fine.

be careful using jdk 14x. there are differences between 13x and 14x and some of the packages or java services may not work under 14x.

Just for clarification, my original question pertains to IS version 6.0.1.

Daniel - I get the same thing as you with the 1.4 JVM, including the one from webMethods and a freshly downloaded 1.4.1_02 from Sun. The 1.3.1 version from the \webMethods\jvm\win.sun13, when copied into the integrationserver\jvm directory (after deleting the original in that location), seems to work.


why use a java service for System.gc() when watt.server.cache.gcMins could be set to the same value as the scheduled service ?

(Specifies how often (in minutes) the server sweeps the cache to perform garbage collection. The default is 60 minutes.)


Hi, Kevin.

watt.server.cache.gcMins and the other watt.server.cache.* services are specific to the Integration Server cache. it is useful to sweep these values, but Ray is specifically talking about cleaning house on the JVM.

In theory, System.gc() doesn’t do a thing – the JVM cleans itself up. And, in theory, System.gc() has such low priority that invoking it should not make a difference. In practice, though, it works.

With regular invocations of a Garbage Collector service, you can manage the JVM’s tendency to grab more resources than its frees. Folks around here will tell you that they use the System.gc() invocation every 30-60 minutes.

Using a scheduled service is the easiest way. Let us know if you need a hand getting it setup.

Hi together,

if you want to use JVM 1.4.x you have to do the following:

  1. Install the JVM 1.4.x
  2. SET JAVA_ROOT=%xxx%:\
  3. Delete the jce.jar from your %xxx%\\jre\lib\ (i’m not sure of the place of the file, name is correct).
  4. Restart the server.
  5. Check in the settings in the About of Administrator.

Hope, i forgot nothing.

Hi David,

     Is It JVM1.4.x supports webmethods6.0.X versions?I think 

it won’t supports.


Hi Srinik,

that’s correct.
But it’s running very fine in two of our projects.
In a SUN environment the performance increases 50%.

Best Regards

Seems like I saw the process for installing JDK 1.4 in some webMethods release notes or documentation, but I cant’ put my hands on it. Has anyone else seen this?


IS 6.0.1 SP1 Readme contains instructions regarding how to modify IS “so that the Integration Server works properly with JVM 1.4.x”. The Readme also notes that JVM 1.3.1 must still be used to compile custom Java services.

We’ve upgraded IS 6.0.1 to use JVM 1.4.x and it’s working fine. Is anyone running the repository server successfully on 1.4.x?

This would involve changing the JVM and optionally setting the -server switch in the following files in the reposerver/bin directory?

This morning I succeeded in getting the WM6.0.1 Repository talking to an Oracle 9i RAC db (v9.2.0) using Suns 1.4.1_02 version of Java. I replaced the JAVA_DIR line in and, will not work with this JVM - UI problems - as far I can tell it will work with the supplied IBM jvm, but you don’t really need it. I now prefer to directly edit the repository2.cnf file located in $IS_DIR/reposerver/config/. Oh yes - very important - use the Oracle thin driver, “oracle.jdbc.driver.OracleDriver” - to do this you must be sure that Oracle’s file gets added to your $REPOCLASSPATH. I know for sure that needs this, I don’t believe repoconfig does but I haven’t fully investigated that.

We’ve also been succesfully running everything under Sun142, including the repo server, developer, and the TN package.
Besides deleting the jce.jar, we did have to add an endorsed dir… \jvm\jre\lib\endorsed with xerces.jar for proper XML handling in a particular package.

I reconfigured the IS 6.01 server on my Windows XP laptop to use Sun JDK 1.4.2. I also added the -Xloggc:<filename> parameter to the java command in the server.bat startup script to write the garbage collection stats to a file for subsequent analysis.

While there are many tools out there to do this, I used the free HPJTune tool available from to create graphs showing garbage collection duration and reclaimed memory amounts.

These are not very interesting on a single-CPU laptop used only for development, but I’m preparing for an upcoming tuning assignment.


Hi Ray. I’m interested to know why you “ramped the system over to the Sun JDK 1.3.1_07 for Windows”. From what I have heard/read webMethods IS performs better on the IBM 1.3.1. JVM.

We are currently running webMethods (6.0.1. SP2) Integration Server under the Sun 1.3.1_09 JVM, on Windows 2000 Server (Service Pack 3 Build 2195). The server is an IBM eServer xSeries 360 (2 hyper-threaded cpu’s), with 6GB of RAM.
Our Java Min and Max memory (in server.bat) are:

Is it worth switching to IBM’s 1.3.1 JVM ? Any other tuning tips ?

We are planning to create a Java service to execute the System.gc() command. This service will be scheduled to run every few minutes. The feedback from this forum and others I have talked to agree that this should be done.

Comments ?