Roll your own Continuous Integration System (C.I.S.): Basic Tomcat configuration - JMX

Roll your own Continuous Integration System (C.I.S.)

Content:

Abstract

Install Tomcat

Basic Tomcat configuration - Memory

Basic Tomcat configuration - JMX

Basic Tomcat configuration - Application Manager and permissions

Apache and uSVN

Installing Artifactory from WAR

Configure Artifactory and MySQL

Configuring Artifactory security and repositories

I continue with this tutorial, this time I will assume you are working with Linux, in order to simplify the installation and configuration explanations. I do not have any license of Windows (no, Verbatim is not a Windows licenser).

JMX is one of those fabulous tools+protocol that almost anybody knows and everybody should know.

It will help you to monitor any application since Java 1.5, it is based on reflexive calls and that guaranties uniform calling to unknown classes.

"The Java Management Extensions (JMX) API is a standard API for management and monitoring of resources such as applications, devices, services, and the Java virtual machine. The JMX technology was developed through the Java Community Process (JCP) as Java Specification Request (JSR) 3, Java Management Extensions, and JSR 160, JMX Remote API. 

Typical uses of the JMX technology include:

Consulting and changing application configuration

Accumulating statistics about application behavior and making them available

Notifying of state changes and erroneous conditions.

The JMX API includes remote access, so a remote management program can interact with a running application for these purposes."

(from here.)

There's an easy-to-use tool for newbies called JConsole (jconsole.exe in Windows or jconsole in Linux), it is brought by JDK >1.5, you will find it in the same folder than java.exe or javac.exe. Find it, execute it, right now, do not wait one more minute.

The first you discover is the connection panel, first half for local applications, second half for remote ones. Local connections will never be empty due to the JConsole application itself is JMX-monitorizable. A monitorizable monitor!! Yehaaa!!!

Close to a dream, data, data, dataaaaaaaa :)

All about JConsole, it shows cpu consumption, memory usage, vm parameters, and MBeans...

MBeans are some special entities in java allowed to be exported like statistics and methods to be run. Indeed, cpu and memory statistic data are extracted from some well-known MBeans, and JConsole takes advance of knowing those MBeans for plotting some graphs. But it could could any metric you define.

Some day, in near future, I will describe how to populate application metrics and methods for being executed from JConsole or your own JMX protocol consumer.

Do not be shy, press that button, you will provoke a Garbage Collector call, and some memory will be freed. Change to memory tab to confirm it.

Summarizing, I find it quite important to monitor our Tomcat server in order to see memory consumption, CPU, and our application exported beans. 

How to get it? It is not difficult.

 http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html#Enabling_JMX_Remote

It has taught me longer than expected to make it run, and the cause is that a line is missing for empty Tomcat6 installation.

The final configuration for Tomcat6 JMX enabled and simply secured is:

 # You can pass some parameters to java here if you wish to
JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Xms1536m -Xmx1536m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+DisableExplicitGC"
 # Enabling JMX 
CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote.port=8091 -Dcom.sun.management.jmxremote.password.file=$CATALINA_BASE/conf/jmxremote.password -Dcom.sun.management.jmxremote.access.file=$CATALINA_BASE/conf/jmxremote.access -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=192.168.1.106"


About the content of jmxremote.password, a simply plain text with pairs of name password like this:
monitorRole tomcat
controlRole tomcat

About the content of jmxremote.access, a simply plain text with pairs of name policy like this:
monitorRole readonly
controlRole readwrite

Note some changes:
1) JAVA_OPTS is redefined with $JAVA_OPTS, in order to preserve some possible variable preset. The same for CATALINA_OPTS.
2) -Djava.rmi.server.hostname is defined in CATALINA_OPTS, with the server address. If not present, JMX module will only handle local calls, even though you set com.sun.management.jmxremote.port.
3)  "com.sun.management.jmxremote" is not needed if "com.sun.management.jmxremote.port is defined."
4) Every variable set in a single line.
5) jmxremote.password and jmxremote.access should be only readable (and only readable) by tomcat user.

Of course, you can apply these instructions to the tomcat6.conf file in Linux, or Start->All programs->Apache Tomcat 6.0->Configure Tomcat. "Java" tab, for Windows, as we did before for memory configuration.

Remember, open Firewall for your JMX port if necessary! 

Now you are able to see Tomcat with codename Catalina in your JConsole panel if you are running it locally, or throw remote connection.

Sorry for the delay, it really got me on my nerves to find the way of populating the jmx service!


Some help for Windows:
http://www.askproductions.no/blogg/2009/02/add-jmx-support-to-tomcat-6-on-windows/