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 to 4096k
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. Supported values are: preemptive Balance every time a session is activated (default). threshold When activating a session, balance only if the current node is busy. That is, only if the memory-in-use is above the threshold or the CPU is above the threshold. none No load balancing.
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 `port.offset` property to ensure that ports from different nodes do not conflict with each other. The default offset for the port is relative to the port in the HTTP server URL. 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 jvm.conf file.

To specify the bind address in the jvm.conf file, enter:

XML

-Dnexj.bind.address=<host/IP>

To specify the bind address in the modeld.conf file, enter:

XML

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:

XML

-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:

XML

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