MASTERTHEBOSS.COM

In this article we'll show how to monitor HTTPSession replication using the JConsole tool. The JConsole can be used to detect bottlenecjs caused by costly session replication on a cluster.

The jconsole tool is a JMX-compliant graphical tool for monitoring a Java virtual machine. It can monitor both local and remote JVMs. It can be also used to monitor and manage an application (as well as the JMX-CONSOLE). One big "plus" of the JConsole tool is the ability to show real-time graph and threasholds of important parameters.

Connecting JBoss to JConsole

 
In order to connect to JBoss AS from JConsole you need to add the following JAVA_OPTS (Windows environment in this sample)

set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote
set JAVA_OPTS=%JAVA_OPTS% -Djboss.platform.mbeanserver
set JAVA_OPTS=%JAVA_OPTS% -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl

We'll deploy a dummy web application which simply fills the HttpSession with lots of data:

<%
java.util.Vector vec = new java.util.Vector();
for (int ii=0;ii<5000;ii++) {
 vec.add("added element " +ii);
}

java.util.Vector vecSession = (java.util.Vector)session.getAttribute("collection");

if (vecSession == null) {
 out.println("added new vector");
 session.setAttribute("collection",vec);
}
else {
 out.println("added data into vector");
 vecSession.add(vec);
}
%>

Pack this jsp in a .war and don't forget to add in the web.xml the <distributable/> tag.

Now start up your jboss cluster and deploy your web application to the farm directory.

Starting up JConsole

JConsole can be found under the "bin" directory of the JDK, so if you have put this folder in the system path simply issue :

$ jconsole

Once started you can connect to the JBoss instance of the cluster you wish, supposing we connect to the first node which is on the same machine as JConsole (so it's considered local instance by JConsole)

First evidence of the problem

If you keep requesting the Jsp you'll soon fill your memory with data which cannot be reclaimed by the garbage collector.
From the memory tab observe the "Survivor Space" and "Tenured Space". As you keep requesting the jsp the surviror space fills up until it overflows the tenured space. This happens as soon as garbage collector is launched. The survivor space will be freed but the tenured space keeps growing. This is the first signal that something is wrong.


JBoss Memory output of Survivor Spaces: notice the peak before Garbage Collection


JBoss Memory output of Tenured Generation

Notice that we can add a threshold to memory areas : in this case we've set  a Threashold of 40 MB for the tenured generation.
When the memory usage of the TenuredGen memory pool exceeds 40 MBytes, part of the bar representing the TenuredGen memory pool will turn red to indicate the portion of used memory that exceeds the usage threshold. The bar representing the heap memory will also turn red.

 

Let's look for more evidence

Move under the MBeans tag and open the jboss.jgroups.protocol.DefaultPartition tree.
Here you can find several useful statistics for your Cluster. Since HTTP Session replication is done with UDP packets, click on the UDP element.


Here you can see how much data is pushed between nodes in order to achieve HTTP Session replication.
As you invoke the "killer jsp" you'll see the Bytes Sent/ByteReceived value growing more and more.
This means that JBoss is moving more and more Bytes to replicate the Huge Session.

JConsole can provide really useful information, in this short tutorial we've seen how we can make sure that your sessions are not getting too large for the costly session replication on a cluster.