Specifying JVM arguments and system properties
You can tune system behavior and performance using JVM arguments and system properties.
The following formats are used for specifying system properties:
- In the environment file:
<propertyName>="<value>"
, for example,port.offset="100"
- In
modeld.conf
:<propertyName>=<value>
, for example,port.offset=100
Using an -X<argument> in the
jvm.conf
file or in the command line:
For example,-Xss4096k
to change the default thread stack size to4096k
- Using a -D<property> in the
jvm.
conf
file or in the command line:-Dnexj.<propertyName>=<value>
, for example,-Dnexj.port.offset=100
The jvm.conf
and modeld.conf
files are located in the <SERVER_HOME>\conf
folder.
There are three types of system properties which can specified in multiple formats.
Specifying general Java system properties
General JVM arguments, including JVM heap size, thread size, and garbage collection time, can be specified in the jvm.conf
file. You can also add JVM arguments using an -X<argument> in the command line when starting the application or when registering NexJ Model Server as a Windows service. If you modify the jvm.conf
file after registering Model Server as a service on Windows, you must unregister and re-register the service for the changes to take effect.
The jvm.conf
file is not used when registering Model Server as a service on Linux. To edit JVM arguments when registering Model Server as a service on Linux, you must modify the JVM arguments directly in the modeld.service
file.
For information about commonly used Java system properties, see https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/optionX.html.
Specifying Tomcat connector system properties
Tomcat connector attributes, such as web container thread pool size, are specified as system properties for Model Server. They can be specified in the following ways:
- In the environment file:
<propertyName>="<value>"
, for example,ajp.maxThreads="200"
- In the
modeld.conf
file:<propertyName>=<value>
, for example,ajp.maxThreads=200
- Using a -D<property> in the
jvm.conf
file or in the command line when running the application:-Dnexj.<propertyName>=<value>
, for example,-Dnexj.ajp.maxThreads="200"
For more information, see Configuring Tomcat connector properties.
For information about common Tomcat connector attributes, see https://tomcat.apache.org/tomcat-8.5-doc/config/http.html or https://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html.
Specifying NexJ application-specific system properties
Like Tomcat connector properties, NexJ application-specific properties, such as node
, port.offset
, and clusterMemoryThreshold
, can also be specified in any of the following ways:
- In the environment file:
<propertyName>="<value>"
, for example,port.offset="100"
- In the
modeld.conf
file:<propertyName>=<value>
, for example,port.offset=100
- Using a -D<property> in the
jvm.
conf
file or in the command line when running the application:-Dnexj.<propertyName>=<value>
, for example,-Dnexj.port.offset="100"
In case of a conflict, the value specified for a property using the -D<property> takes precedence, followed by the value specified in the modeld.conf
file. If a value is not specified by either of these methods, then the value specified in the environment file is used.
All NexJ application-specific system properties can be edited in the environment file in the Deployment layer of NexJ Studio. If you are using the environment file as a template, you can include these properties in the environment file and specify the exact values for your specific deployment in the properties file.
The following are some of the properties that affect system performance and behavior.
Property | Description |
---|---|
balancing | Specifies the session load balancing algorithm. Load balancing occurs when a session is restored from the persistence store. If the session is load balanced, requests are redirected to another node by an external load balancer. preemptive threshold none |
channelWarningTimeout | Timeout in milliseconds after which a warning is generated. The value of 0 indicates indefinite. The default value is 1000. |
clusterBroadcastAddress | The network broadcast address, which sends your IP address to a range of broadcast IP addresses simultaneously and receives on your own IP address. If not specified, the default value is 255.255.255.255. |
clusterCPUThreshold | The CPU usage at which a node is considered busy. Specified as a percentage, up to 100. |
clusterMemoryLimit | The memory usage at which a node is considered overloaded, expressed as the percentage of utilization of the total heap. This is the maximum memory usage allowed before session passivation is forced. When the object queue dispatcher node becomes overloaded, it initiates pre-emptive failover and a new non-busy node is selected to be the dispatcher. |
clusterMemoryThreshold | The memory usage at which a node is considered busy, expressed as the percentage of utilization of the allocated heap. |
clusterMulticastGroup | The multicast group to join. The value is chosen from a reserved range of IP addresses and sends and receives to multicast IP addresses. If not specified, the default value is 239.192.10.1. |
maxPoolSize | Maximum database connection pool size per server. |
minPoolSize | Minimum database connection pool size per server. |
port.offset | When running two or more nodes on the same server, specify the For example, if the HTTP server URL is http://host.domain.ext:7080/nexj and the port offset is 100, the JVM will listen to port 7180 for HTTPS traffic. |
persistentSession | Enables session persistence and load balancing. Session information is stored using a file system or a database. |
transactionTimeout | The default transaction timeout in seconds. The value of 0 indicates infinite timeout. |
For information about properties related to auditing (eventAudit, readAudit, and updateAudit), see Configuring audit trails.
Binding a JVM to a specific host or IP
You can bind a JVM to a specific host or IP address using the bind.address property. You can specify this property in the modeld.conf
file or using a -D<property> in the
file.jvm.conf
To specify the bind address in the jvm.conf
file, enter:
-Dnexj.bind.address=<host/IP>
To specify the bind address in the modeld.conf
file, enter:
bind.address=<host/IP>
Updating the location of the JVM directory contents
In some cases, when using custom libraries such as DynaTrace or Jolokia as part of your integration, you may want to augment the NexJ Server jvm
folder with contents from another location to avoid any accidental overwriting of the files. To do this, you can use the bootstrap.classpath.suffix argument.
For example, include the following code in the jvm.conf
file to augment the jvm
folder contents with those from the /opt/nexj/publish/
directory:
-Dnexj.bootstrap.classpath.suffix=/opt/nexj/publish/*.jar
Overriding environment file property settings
When using a template environment file and a .properties file for environment-specific settings, you can use the -Dnexj.server.property.override.<property>
JVM directive to override settings.
For example, you can run the following batch command:
modeld.bat -d localhost:<portNumber> -s "-Dnexj.server.property.override.RDC.database=unittest" -M <SERVER_HOME>/workspace/meta -C c:\work\ws\enterprise\env\Build.environment -P c:\work\ws\enterprise\env\Build.properties