Monitoring in JBoss

While at a client site or within a testing environment, have you ever started to wonder how many users are on the application? How is your application running with regards to memory (heap size)? Are you close to using all of the database connections in the connection pool? For answers to some questions, maybe your application container provides a status (tomcat) or monitoring screen (WebLogic).

To facilitate recording of these statistics when using JBoss, JBoss has included the ability to log/monitor JMX Mbean values. And it's not difficult to install. Once values are being logged, you no longer have to continue refreshing the JMX console to see the values updated.

For installing and monitoring of your web application(s), perform the following steps:

1. Copy monitor XML files into $JBOSS/server/server_name/deploy
2. Copy $JBOSS/docs/examples/jmx/logging-monitor/lib/logging-monitor.jar into $JBOSS/server/server_name/lib
3. Create monitor XML files to monitor JMX MBeans (samples below)

And there you have statistics being saved in a log file...ready for you to parse and create pretty little graphs for the rest of the world to read and understand. For our deployments, we used these logs to track & monitor the following items. As a side affect of monitoring, you also get to see the peak usage times and potentially performance / memory related issues.

• DB connections
• In use
• Available
• Max Connections In Use
• JVM activity
• Heap size
• Threads

For additional reading or research on monitoring within JBoss, check out the following links:

• JBoss Monitoring
• Managing and Monitoring JBoss

DB Connection Monitoring Sample
Here's the XML necessary to monitor a JDBC connection pool (XML comments omitted)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE server PUBLIC
"-//JBoss//DTD MBean Service 4.0//EN"
"http://www.jboss.org/j2ee/dtd/jboss-service_4_0.dtd">

<server>
<mbean code="org.jboss.services.loggingmonitor.LoggingMonitor"
      name="jboss.monitor:type=LoggingMonitor,name=MY-DSMonitor">

  <attribute name="Filename">${jboss.server.home.dir}/log/my-ds.log</attribute>

  <attribute name="AppendToFile">false</attribute>

  <attribute name="RolloverPeriod">DAY</attribute>

  <attribute name="MonitorPeriod">10000</attribute>

   <attribute name="MonitoredObjects">
      <configuration>
         <monitoredmbean name="jboss.jca:name=MY-DS,service=ManagedConnectionPool"
                         logger="jca.my-ds">
            <attribute>InUseConnectionCount</attribute>
            <attribute>AvailableConnectionCount</attribute>
            <attribute>ConnectionCreatedCount</attribute>
            <attribute>ConnectionDestroyedCount</attribute>
            <attribute>MaxConnectionsInUseCount</attribute>
         </monitoredmbean>
      </configuration>
   </attribute>

  <depends>jboss.jca:name=MY-DS,service=ManagedConnectionPool</depends>
</mbean>

</server>

Utilizing OpenSymphony Caching (OSCache) with iBatis

Background

My current project is ramping up to be deployed into a centrally hosted data center to be accessed by a large volume of users. In past deployments, we could expect, at most, 200-300 users to be logged into our web application. When translating that number to active users, we can expect somewhere in the range of 25 to 100 active users at any given point in time.

With deployment into a centrally hosted environment, our anticipated user base significantly increases to be approximately 1000 concurrent, active users. With this large number of users, we wanted to investigate caching frequently accessed objects.

The major area in our web application that currently utilizes caching is at the DAO level. Our DAOs are leveraging iBatis and already using iBatis in-memory cache implementation. Moving to a centrally hosted environment, the application will be clustered. Thus, supporting fail-over and high availability. However, using the iBatis cache, we risk the possibility that users see different objects depending upon their assigned clustered instance and when the iBatis cache is refreshed. To synchronize cache flushing across the cache, we decided to investigate incorporating a distributed caching mechanism. With iBatis supporting OSCache, we decided to start there.

Implementation

As mentioned previously, iBatis documentation refers to using OSCache for distributed caching within a clustered environment. Assuming you are using maven to build your project, configuring iBatis to use OSCache is extremely easy and well documented.

1. Modify the project's pom.xml to include oscache.jar (2.4) as a dependency
2. Identify and modify the sqlMap / DAO that you wish to use oscache. change cacheModel type to be "OSCACHE"
3. Optionally include an oscache.properties file on the class path. Within development or continuous integration (CI) environments, this file does not need included as default properties will be applied. Deployment in production or other test areas can include the file.

For configuration options and settings including clustering instructions, refer to OSCache web site. The clustering option sends a flush event that causes all caches within the cluster to be flushed. Currently, OSCache can be configured to send flush events via JMS or JavaGroups (multi-cast). All of the settings are nicely documented.

http://www.opensymphony.com/oscache/wiki/Configuration.html
http://www.opensymphony.com/oscache/wiki/Clustering.html