Apache Tomcat is a Java Web Server that runs Web Application Resource (WAR) files, a common way to run Java applications. A common tuning parameter is the amount of heap space (memory) allocated to the Java process that runs Tomcat. How to set it, and to monitor and change it on Windows when Tomcat runs as a service is not obvious. We will explore running Tomcat on Windows. Add a comment if you see something that you feel is missing!
We will go through four relevant things:
To install, download the latest version of Tomcat from Apache. Unpack/install to the desired location. Once the Tomcat installation is in place, you need to register the Tomcat service with Windows. Most people use the default to run it as SYSTEM, which is not necessarily recommended. It is always a security risk involved to run a service as SYSTEM, it is better to run it under a service account! The setup in this file will most often apply to already running Tomcat instances I’m afraid, running as SYSTEM.
All commands expects us to be running in CMD.EXE as Administrator. We run the commands from the root of the Apache Tomcat directory structure, at the same level as the bin, conf and logs directories.
To enable the Tomcat service on Windows. It is optional to append the Windows service name you want to use:
.\bin\service.bat install or .\bin\service.bat install tomcat_service_name
You may need to configure the jvm.dll location if the Java installations messed up (or set the JAVA_HOME environment variable correctly). The
jvm.dll location is set in the Tomcat config interface, and the file is found the the bin/client folder of the Java JRE installation.
The main Tomcat runtime settings are found in the
Java tab, including the memory settings, which seems to be set to 256MB by default. The default is not enough for large applications. To increase the available memory in the Java process, increase the “Maximum memory pool”.
Find your settings in the Tomcat configuration interface. To find the service name for it, check
services.msc. In the example it’s Tomcat7.
The Java Management Extensions are needed more on Windows than on Linux/Unix. The reason is the context split in Windows between regular users and SYSTEM, which is the user Tomcat often runs as on Windows. I recommend to run Tomcat under a service account with less privileges. On Linux/Unix, it’s much easier to attach to processes directly across contexts, thus reducing the need for the JMX setup.
The Java Management Extensions provide a wealth of options to manipulate and monitor Java processes for all kinds of purposes. Yet, with great abilities, comes great responsibility.
I have not yet found a way to setup SSL connections in a portable and easy way for administrators, but SSL is recommended to be setup if running JMX over a corporate network. It seems both client and server needs to have SSL certificate pairs and trust each other, which is not that easy to manage, or to setup a PKI infrastructure. The challenges led me to drop the SSL setup for now.
This article sets up the basics of a JMX setup, to be used in local environments only. For this setup I recommended to only have readonly access with this setup, even if readwrite is possible. The host should be firewalled to only accept connections from trusted hosts.
To get started, there are three main parts of getting the JMS extensions running:
Open the Tomcat configuration interface again and head to the
Java tab to add the necessary options:
Add below Java options (no SSL, use access and password file for authentication):
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8008 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.password.file=conf/jmxremote.password -Dcom.sun.management.jmxremote.access.file=conf/jmxremote.access
All file paths are relative to where the CATALINA_HOME variable points, and the forward slash is permitted on Windowa within the Java context.
The access configuration works with temporary files to allow you to iterate passwords and access using the file securing commands. Delete the
_copy files when you are done with the configuration. The completed files are locked down.
Create a file in the
conf directory, named
jmxremote.access_copy, with below contents:
## username roleType jmxread readonly #jmxuser readwrite
The access file tells the JMX extensions what kind of access the user (on the left) should have.
Create a file in the
conf directory, named
jmxremote.password_copy, with below contents:
## username password jmxread mypass #jmxuser mypass
The user is on the left and must match the access configuration user. The password “my pass” obviously needs to be changed!
Tomcat checks that the contents of the files are not visible to the world, and readable only by the SYSTEM process, when Tomcat runs as SYSTEM. This was a challenge to figure out, but possible to do from the command line. The icacls and cacls commands manipulate file permissions, and the “echo Y|” is the equivalent of a forve flag.
It is expected the above text files are created with the _copy suffix until configuration is complete.
del jmxremote.access jmxremote.password copy jmxremote.access_copy jmxremote.access copy jmxremote.password_copy jmxremote.password icacls jmxremote.password /setowner system icacls jmxremote.access /setowner system echo Y| cacls jmxremote.password /P SYSTEM:R echo Y| cacls jmxremote.access /P SYSTEM:R
When you have set it up according to your taste and changed the passwords, delete the
del jmxremote.access_copy jmxremote.password_copy
Java includes a number of tools in the Java Development Kit. If you encounter issues, make sure to match the Java Runtime Environment (JRE) with the JDK version. The JDK does not have to be installed on the Tomcat server to access the JMX extensions of you connect over the network. However, the SSL setup should be in place when you connect as passwords are visible in clear text over the network otherwise!
Two main tools are provided in the JDK,
jvisualvm. I found the jconsole tool more complete, but both are highly usable.
From the command line, there are several tools:
jstackshows all threads stack traces
jinfoshows java process information, including java options
jstatmakes java process information available to monitor on
I found the following resources helpful when researching the solution: