JVM Settings
When VirtServer runs, it provides several parameters to the Java Virtual Machine (JVM) to set up the environment. You can modify these parameters according to your needs.
The VirtServer installer creates a *.vmoptions file that contains default JVM arguments. Here is a sample snippet of that file:
-include-options [path to other .vmoption file] -Xms128m -Xmx7880m -Dsoapui.properties=soapui.properties -Dsoapui.home=C:\Program Files\SmartBear\VirtServer-3.26.0/bin...
To modify these settings, open the *.vmoptions file with a text editor. You can change existing parameters or add new ones. Administrative privileges are required to edit this file.
Custom JVM Options
Add a file named userdefinedvmoptions to the .readyapi/virtserver directory to specify custom JVM options. This file allows you to add JVM parameters that persist through VirtServer updates and upgrades to newer versions, ensuring your custom settings remain intact.
Java Virtual Machine Parameters
This section describes variables that VirtServer passes to the Java virtual machine to prepare the environment.
-Xms<value>
Specifies the initial size of the heap (memory) to be used in bytes.
Append k or K to specify the value in kilobytes, and k or K to specify the value in megabytes.
Example:
-Xms128m
-Xmx<value>
Specifies the maximum size of the heap (memory) to be used in bytes. Default value: 7880m.
Append k or K to specify the value in kilobytes, and k or K to specify the value in megabytes.
Example:
-Xmx7880m
-Dsoapui.virt.optimizeForPerformance=<value>
In ReadyAPI 3.40.1, we added a synchronization update to ReadyAPI to improve accuracy when handling bulk requests. The synchronization update has improved the balance between accuracy and response rate/time. However, this may impact the speed of ReadyAPI response for some customers using Virtual Services as part of performance testing.
As a solution, we added a feature flag that allows you to configure this setting. You can now prioritize processing speed over accuracy according to your requirements.
This flag can be controlled by modifying the VMoptions file in /readyapi_install_dir/bin/virtserver.vmoptions. The default value is false if the flag is not present in the VMOptions file.
To enable this feature, add the following line to the virtserver.vmoptions file:
Example:
-Dsoapui.virt.optimizeForPerformance=true
-Dcli.http.timeout=<value>
Configures the timeout for VirtServer CLI.
When deploying large project files (>400M) via the CLI, you might encounter a java.net.SocketTimeoutException error message. We have made timeouts configurable through the addition of a vmoption.
Example:
-Dcli.http.timeout=60000
A successful response should read:
[INFO] Virt <virtual service name> successfully replaced on server with deployment id 1.
Conditional Match JVM Options
Set a Default Response per Signature
You can set a default response for each signature. This response is sent when an incoming request matches the signature but lacks a corresponding specific response. If the request doesn’t match any signature, the global default response is used.
To enable this feature in ReadyAPI, go to Preferences → Virtual Service and select the Enable default response per signature option. Once enabled, you can choose a default response for each signature, which will be used if the request matches the signature but doesn’t have an associated response.
To configure the corresponding support in VirtServer, add:
-DdefaultResponsePerSignatureEnabled=true.
Setting Dates Delta Using Property Expansion
The Dates Delta feature allows you to use property expansion for date values in Conditional Match. In ReadyAPI, you can specify the date format as dd-MM-yyyy in Preferences → Virtual Service. This ensures that responses can have date values relative to request dates.
When Enable conditional match dates property expansion is set to true, the new syntax is automatically applied during record from traffic.
To configure the corresponding support in VirtServer, add: -DmagicDatesFormat=yyyy/MM/dd (or other format, per your preference).
VM Option Configuration for Route to Live
Additional Configuration Required for Route to Live:
When using Route to Live for Virtual Services deployed to VirtServer, ensure the appropriate vmoptions are configured in the following scenarios:
To allow restricted headers.
If the backend server uses a self-signed certificate.
If a proxy is enabled.
Configuration for Linux
To allow restricted headers: Add the following option:
-Djdk.httpclient.allowRestrictedHeaders=connection,content-length,expect,host,upgrade
When starting as an application: Add the required VM option to the virtserver.sh file.
When starting as a service: Add the required VM option to the virtserver.vmoptions file.
If the backend server uses a self-signed certificate: Add the following option:
-Djdk.internal.httpclient.disableHostnameVerification=true
When starting as an application: Add the required VM option to the virtserver.sh file.
When starting as a service: Add the required VM option to the virtserver.vmoptions file.
If a proxy is enabled: Add the following option:
-Djdk.http.auth.tunneling.disabledSchemes=""
When starting as an application: Add the required VM option to the virtserver.sh file.
When starting as a service: Add the required VM option to the virtserver.vmoptions file.
Configuration for Windows
When starting as an application: Add the required VM option to the
virtserver.shfile.When starting as a service: Add the required VM option to the
virtserver.vmoptionsfile.