JAVA_OPTS Parameters

In the catalina.sh of Tomcat, a number of parameters are set through the JAVA_OPTS setting. This topic explains those parameters. For specific environments, the values of these parameters can be tailored to your requirements. For a full description of the Java virtual machine (JVM) options see http://java.sun.com/javase/technologies/hotspot/JVMoptions.jsp.

In This Topic

General Parameters

-server

The client system is optimal for applications which require fast startup times and/or small footprints. The server system is optimal for applications where the overall performance is most important. Since startup is less important to XperienCentral than overall performance, the server system should be used.

-Duser.language=en  and  -Duser.country=US

These two options set the locale of the JVM and are mostly used to avoid problems while running on the Oracle database. The Oracle server is mostly installed with the en_US locale. If the JVM (in which XperienCentral is running) communicates with the Oracle server, it uses by default the locale of the operating system. If that locale is set to, for example, nl_NL, then problems might arise with date formats. To avoid any issues it’s best to set the locale of the JVM to en_US and install the Oracle server with that locale too.

–Xmx1024m

This option sets the maximum heap size for the Java Virtual Machine (JVM). XperienCentral uses memory for caching content from the database. A low value for this option can cause excessive garbage collection overhead and a lot database accesses. This option should be tuned based on the performance requirements of the application like number of concurrent users and the size of the content. If more memory is assigned to XperienCentral, more content can be cached in memory and the overhead of database access can be avoided.

Assigning more memory to the JVM will generally improve the performance. However, (excessive) swapping should be avoided as much as possible. Another drawback of a large heap is the fact that a full garbage collection will take more time. If the garbage collector uses a stop-the-world garbage collection policy, XperienCentral will be unresponsive for a longer period of time.

–Xms512m

This option sets the minimum heap size for the JMV. Setting a minimum heap size can improve startup time.

-Ddisable_2fa

Disables XperienCentral's two factor authentication.

-Djava.awt.headless=true

This option should be set to make sure the server is able to manipulated images without the presence of a display.

-Djava.locale.providers=COMPAT,CLDR

CLDR is a project of the Unicode Consortium to provide locale data in XML format. It contains locale-specific information that an operating system will typically provide to applications.

-Dsun.net.inetaddr.ttl=300

This option determines the number of seconds that the result of a hostname lookup should be cached in the JVM. The default behavior of the JVM is to cache it until a restart. This, however, is not desirable on a production environment. By adding this parameter with the value 300, the result of the hostname lookups stay cached for 5 minutes.

-Dorg.apache.jasper.runtime.JspFactoryImpl.USE_POOL=false"

This system property disables Tomcat JSP custom tags pooling which can cause memory leaks in XperienCentral.

–Dwebmanager.clustering.id=x

This system property uniquely identifies an XperienCentral server in a clustered environment.

–Dwebmanager.clustering.readonly

This system property specifies that this XperienCentral server in a clustered environment does not have write access to the filestore.

–Dwebmanager.clustering.filestore=

This system property specifies whether the XperienCentral servers in a clustered environment use the custom XperienCentral filestore to synchronize files between them.

–Dwebmanager.clustering.scanner.interval

This system property controls how often uncontrolled files in a clustered environment are synchronized. The interval is in milliseconds.

-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl

This command specifies the TransformerFactory implementation to use. This command must be implemented.

-Djava.net.preferIPv4Stack=true

If IPv6 is available on the operating system, the underlying native socket will be an IPv6 socket. This allows Java(tm) applications to connect as well and accept connections from both IPv4 andIPv6 hosts. If an application has a preference to only use IPv4 sockets, then this property can be set to true. The implication is that the application will not be able to communicate with IPv6 hosts.

-Djdk.xml.xpathExprGrpLimit

This JDK system property sets the maximum number of nested groups allowed in an XPath expression. This property is used to limit the complexity of XPath expressions in order to prevent potential security vulnerabilities or performance issues that may arise from processing overly complex expressions. By default, the limit is set to 10, but it can be adjusted as needed for specific applications or use cases. GX Software recommends a value between 25 and 60.

-Djdk.xml.xpathExprOpLimit

This JDK system property sets the maximum number of operations allowed in an XPath expression. This property is used to limit the complexity of XPath expressions in order to prevent potential security vulnerabilities or performance issues that may arise from processing overly complex expressions. By default, the limit is set to 10000, but it can be adjusted as needed for specific applications or use cases. GX Software recommends a value between 400-5000.

-Djdk.xml.xpathTotalOpLimit

This JDK system property sets the maximum total number of operations allowed in all XPath expressions evaluated during the execution of an application. This property is used to limit the overall complexity of XPath expressions in order to prevent potential security vulnerabilities or performance issues that may arise from processing overly complex expressions. By default, the limit is set to 1,000,000, but it can be adjusted as needed for specific applications or use cases. GX Software recommends a value between 15,000 and 25,000.

-Dorg.jackrabbit.repositoryfile

This system property should contain an absolute path to the repository.xml file when used. This makes it possible to place the repository.xml and accompanying repository-1.5.dtd files in a location other than work/jcr.

-Dwebmanager.configuration.startup

This system property should contain an absolute path to the startup_config.xml file when used. This makes it possible to remove the startup_config.xml file from the backend .WAR and place it in a user-defined location on the file system.

-Dwebmanager.configuration.initial

This system property should contain an absolute path to the config.xml file when used. This makes it possible to remove the config.xml file from the backend .WAR and place it in a user-defined location on the file system.

Back to top

Garbage Collector Parameters

The garbage collection algorithm should be tuned to the characteristics of the XperienCentral application. XperienCentral caches content in memory. The content is stored in the tenured space. Cleaning up this tenured space would usually require a full garbage collect. Long garbage collection pauses should be avoided as much as possible. A long pause does not only make the site unresponsive but it also causes clients to send duplicate requests and causes a build-up of open requests on the server.

Stop-the-world pauses can be minimized by using the concurrent mark sweep collector. It performs most garbage collection activity concurrently, While the application threads are running it keeps garbage collection-induced pauses short. This is especially useful if there are unused processors available on the server. A slight drawback of this collector is that garbage collection uses some more CPU instructions.

-XX:+UseConcMarkSweepGC

The concurrent mark sweep collector should be activated using the command-line option -XX:+UseConcMarkSweepGC.

-XX:+UseParNewGC

The new generations can be collected in parallel.

-verbose:gc

The overhead of the garbage collector can be measured and logged by setting the JVM option -verbose:gc. The duration of the garbage collections are logged in the Tomcat catalina.out. If the overhead becomes a problem, this log can be used for analyzing and tuning the garbage collector.

-Dsun.rmi.dgc.client.gcInterval=600000

The content of XperienCentral is indexed by the XperienCentral search engine. This search engine is a separate application which runs in its own virtual machine. RMI is used as the protocol for communication between the XperienCentral server and the search engine. RMI forces periodical full garbage collections in order to make sure all objects in the distributed environment can be freed. The default interval for this is one minute, which leads to a stop-the-world full garbage collect every minute. This creates detrimental performance issues especially for large heaps. Setting this interval to ten minutes will not cause any problems because the number of RMI calls and the corresponding garbage is limited. If the full garbage collects still cause problems, this value could be changed to one hour (3600000).

-XX:+HeapDumpOnOutOfMemoryError

If an XperienCentral application throws an OutOfMemoryError and profiling locally doesn’t solve the problem, the JVM can be instructed to dump the contents of the heap to disk for analysis. This option should not be turned on by default on production environments because dumping the heap is stop-the-world and may take a long period of time.

-XX:-ReduceInitialCardMarks

A flaw in the implementation of a card-marking performance optimization in the JVM can cause heap corruption under some circumstances. This issue affects the CMS garbage collector prior to 6u18, and the CMS, G1 and Parallel Garbage Collectors in 6u18. The serial garbage collector is not affected. Applications most likely to be affected by this issue are those that allocate very large objects which would not normally fit in Eden or those that make extensive use of JNI Critical Sections (JNI Get/Release*Critical).

jdk.xml.xpathExprGrpLimit is a system property in the Java Development Kit (JDK) that sets the maximum number of nested groups allowed in an XPath expression. This property is used to limit the complexity of XPath expressions in order to prevent potential security vulnerabilities or performance issues that may arise from processing overly complex expressions. By default, the limit is set to 10, but it can be adjusted as needed for specific applications or use cases. The value of this property can be modified using the -D command-line option when running Java applications or by setting it programmatically using the System.setProperty() method.

25-60

jdk.xml.xpathExprOpLimit is a system property in the Java Development Kit (JDK) that sets the maximum number of operations allowed in an XPath expression. This property is used to limit the complexity of XPath expressions in order to prevent potential security vulnerabilities or performance issues that may arise from processing overly complex expressions. By default, the limit is set to 10000, but it can be adjusted as needed for specific applications or use cases. The value of this property can be modified using the -D command-line option when running Java applications or by setting it programmatically using the System.setProperty() method.

400-5000

jdk.xml.xpathTotalOpLimit is a system property in the Java Development Kit (JDK) that sets the maximum total number of operations allowed in all XPath expressions evaluated during the execution of an application. This property is used to limit the overall complexity of XPath expressions in order to prevent potential security vulnerabilities or performance issues that may arise from processing overly complex expressions. By default, the limit is set to 1000000, but it can be adjusted as needed for specific applications or use cases. The value of this property can be modified using the -D command-line option when running Java applications or by setting it programmatically using the System.setProperty() method.

15,000-25,000