Notes, limitations, and troubleshooting - Java over HTTP
This section describes notes, limitations, and troubleshooting for the Java over HTTP protocol.
Tip: For general VuGen troubleshooting and limitations, see Known issues for VuGen.
- For supported JDK versions, see the JDK support matrix.
Although .NET-based and Java protocols support creating threads, we recommend that you do not use background threads in real load testing scenarios because:
Threads can degrade tests scalability.
Threads can affect performance measurements.
The utility functions' behavior is undetermined if called from any thread except the Vuser main thread which runs the vuser_init, Action, and vuser_end actions. This applies to all functions named lr*.
Java over HTTP supports asymmetric Java object traffic. This means that object serialization traffic is recognized even when it is on only one side of the communication. This occurs when the request is serialization and the response is plain HTTP, or vice versa.
- 64-bit replay is not supported for Java over HTTP.
- Snapshots are not supported for Java over HTTP.
- Due to a restriction in JVM architecture, a method cannot exceed 64 KB.
You cannot use the GWT DFE extension or other Java-compatible DFE extensions. This is a result of a limitation of VuGen’s mdrv process, which only allows you to instantiate a single JVM.
- Lazy evaluating objects are not supported, for example hibernate in lazy mode.
- If there are stateful serialization mechanisms on the application server, this can interfere with VuGen's deserialization and result in unserialized data and unexpected errors.
The Remote Application via LoadRunner Proxy > Display recording toolbar on client machine option, is not supported for the Java over HTTP protocol. For details, see Start Recording Dialog Box.
When you run a Java script, the replay status may be "Script Not Run" and some errors may appear in the mdrv.log file. However, due to Java internal architecture, these errors may not be included in the VuGen Output and Errors panes. This occurs when VuGen fails to initialize a Java Vuser, and JVM then terminates the replay process.
Workaround: Look for errors directly in the mdrv.log file. If the entry in the log is due to a memory-related issue, try using different memory options for Java in the runtime settings.
If you are receiving exception errors and you are sure that the error is irrelevant, VuGen allows you to disable all such error messages. To do this, select Replay > Runtime Settings > Java VM node. In the Additional VM Parameters field, and append the following string to the end of the current entry:
Additionally, you can change the error checking behavior of a specific step by adding a closing argument to the sendSerialized function in script view. For more information, see the Function Reference.
When you need to correlate or parameterize data that is a private member of an object, you can use the lrapi.lr2.fieldSetter and lrapi.lr2.fieldGetter functions.
RemoteInvocation RemoteInvocation2 = (RemoteInvocation) JavaHTTP.readObject(RemoteInvocationBA0); RemoteInvocation.methodName="applyToSchool"; Student student=RemoteInvocation.arguments; Map grades=lr2.fieldGetter(student,"grades");//grades is a private member of Student grades.put("Math","95"); lr2.fieldSetter(student,"super.name","Tom"); //Student class inherits the name field from Person. name field is a string lr2.fieldSetter(student,"super.ID","98764321"); //Student class inherits the ID field from Person. ID field is an int RemoteInvocationResult RemoteInvocationResult_ArrayList2 = (RemoteInvocationResult) JavaHTTP.sendSerialized(RemoteInvocation2, 2, "ObjectsDeserializerDefaultImpl",....