Hi Michelle,

I tested with LRE CE 24.3.1 and I can run with jdk17.0.2_8 and jdk21.0.4_7, . We use AWS Corretto Java in our organization. I see that Java 22 is a non-LTS version.

I've two suggestions:

1. When I use jdk22.0.2_9 it fails in VuGen, so stick with jdk21.
2. When I have to enter a Java path in the Run Time settings I specify up to the jdk_X_Y_Z and not upto bin. (E.g. C:\Program Files\Amazon Corretto\jdk21.0.4_7)

Success, Erik

Hi Erik,

Thank you for the suggestion.

I'm using jdk 17 now. The script is still not running on LRE but it looks better now. 

I've changed my setting to the following:

Errors - 

LG might suffer from too long paths (more than 264 characters or alike).

Make sure that you install OneLG as C:\OneLG and not diep down C:\Program Files (x32)\....
The same might be true for Java, but your Java path does not look too bad.

I do have all the OneLG installed as "C:\Program Files (x86)\OpenText\LoadRunner OneLG". Might consider reinstall, but very unlikely to go with this. 

The script that I'm running is JavaRecordReplay, trying to connect RedShift DB. Once the DB connection is established, execute one sql query.  

Here's my configuration - 

On the LG machine, I have jdk17. 

JAVA_HOME = C:\Program Files\Java\jdk-17.0.12

Path = C:\Program Files\Java\jdk-17.0.12\bin

I've set an Inbound Rules in Firewall - allowed Port 5439, and I'm able to make a DB connection on the LG machine.

On the Loadrunner Settings, I have:

I've saved the redshift driver in LG machine = C:\Program Files\jdbc_driver\redshift-jdbc42-2.1.0.30.jar

4 minutes later, I got a timeout error.

 Michelle Chung , hard to say what issue is. You might build up step by step:
Create Java script that only logs "Hallo World", that might prove that LG with Java is OK.

I've also Java scripts that use JDBC classes, but I've put those in my script folder and have a relative path as class path:
e.g. ./ini4j-0.5.1.jar Note the forward slash, you will get an error but ignore.


I added also the jar file in the Extra Files section. 

Loading of JDBC drivers normally goes via DriverManager.getDriver(). When you have an global ClassPath env. var set, this might give issues in finding the right JDBC driver.I normally try to stay away from environment variables.

Tip add a log writer with DriverManager.setLogWriter() that writes to LR log functions.

Thank you for the suggestion. 

I tried to run a simple script, just printing out some output messages



The vugen script works fine and returns a printout on my local desktop, WITHOUT a classpath. 

Here's the error that i'm seeing on LoadRunner Enterprise web interface:

All of them came from the load generator machine. 


It is a bit odd to see these errors. I have Java installed on the load generator machine, both JAVA_HOME and PATH are in the environment settings, and able to run a java class file. As for the script path is too long, we've been running other type of protocol just fine for other projects from the same repo folder. 

 Michelle Chung ,

What are the costs of deinstalling OneLG and reinstall it at C:\OneLG\ (is also suggested in the installer with LRE 2024.3).

We have put this requirement for all teams that install a LoadGenerator Overfirewall. We do not accepts LGOs that are installed otherwise.

Did you ever explore the temporary created folder structure on an LG during a run? There is much more going on with some protocols like Java or DevWeb.

Sorry for the late reply. We have other projects that are working fine on these machines at the moment, so I decided not to uninstall and reinstall.

I tried to uninstall/reinstall one of our Controllers (not the server, the machine that instructs LG to execute the test), and now I cannot add it back to the host... 

One thing I would like to confirm is... I have both Java and OpenText installed under Program Files (x86). Is this the right way?

(Load Generator machine)

Just really confused with why Vuser failed to initialize extension java_int.dll.

This file can be found here

"C:\Program Files (x86)\OpenText\LoadRunner OneLG\bin\java_int.dll" and "C:\Windows\System32\java_int.dll".

 Michelle Chung (mchungmitre469 ,

Your effort on Controller looks to me not the right approach.

"We have other projects that are working fine on these machines at the moment" I assume that those are not Java based projects.

When you work with a 32bit Java, you should install it under "Program Files (x86)", the 64 bit should go under "Program Files". It might be that a full Java version also installs some components under system32, but I'm not sure about this. I use only relocatable java versions (they do not tamper with Windows settings like system32 and PATH environment variable).

You need real on-hand support with good LRE understanding and administration skills to help you out. I guess make a support ticket so that support can work thinks out without.

Note: Which brand of Java do you have installed? The one of Oracle might give legal issues in a business environment.