Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Add Object Cache Monitoring Using JMX and Aspects

Find out how to add cache monitoring to your applications using JMX MBeans and AOP technologies—without altering the application code.


WEBINAR: On-Demand

Unleash Your DevOps Strategy by Synchronizing Application and Database Changes REGISTER >

ike many companies, my company uses an object cache to store frequently accessed data in memory so the server doesn't have to access the back-end database every time it handles a request for the same data. Caching provides advantages such as application performance improvement, scalability and minimizes the overhead required to acquire and release the objects. In a recent project we needed to view and monitor the cache details (using a Web console) to study the data access trends for objects stored in the cache and determine which objects were better used by storing them in the cache instead of directly going to backend data store. We wanted to use the Java Management Extensions (JMX) technology for this requirement, but didn't want to change any existing application code because we weren't sure how much overhead the monitoring code would add. We decided to use Aspect Oriented Programming (AOP) techniques to dynamically introduce JMX code into existing Java classes and get the cache statistics that way. That way, if the monitoring overhead turned out to require too much overhead, we could easily unweave the JMX code from the application code, returning it to the exact state it was in prior to introducing the monitoring logic.

This article provides an overview of an Object Caching Monitor framework developed using JMX and AOP technologies. The article code uses Aspects to add monitoring capabilities (via JMX) into the Object Caching framework. Why Monitor a Cache?
You can store any type of data in the cache, but the benefits increase when the data is accessed frequently and when it takes more time and resources to retrieve the data from the source, such as a database, than from the cache. When the cache is being used to store different types of data, cache monitoring becomes an important task from several different points of view, because you need to:

  • Know how objects in the cache get cleaned up on a regular interval.
  • Verify that objects stored in the cache are not taking too much memory—which could cause performance problems in the application.
  • Detect when the cache size grows beyond a maximum allowed threshold and raise any alerts to cleanup the cache.
What You Need
JBoss4, JBossCache, Eclipse, AJDT, and Ant

Monitoring in Java Enterprise Applications
Application monitoring and gathering statistics is an integral part of a Java enterprise application. These tasks should be given considerable importance right from the modeling and design phases of a project—not just tacked onto the implementation and post implementation phases. Developers should be involved in all the monitoring requirements of the application. Network administrators and operations groups should work collaboratively with the developers to understand the different parts of the application that will require monitoring when the application reaches a production environment. Application monitoring provides several benefits to all these IS groups. For example, developers can monitor the applications to explore any parts of the application that may need tuning and optimization, while the operations and network admin groups can use monitoring tools to detect O/S or server problems before they occur and to trigger warnings when server statistics such as CPU or memory usage approach the maximum allowed limits. Many areas in a Java application and the application server can benefit from monitoring to create a scalable and highly available Java EE application. Table 1 shows some of the items that you should consider monitoring.

Table 1: The table shows some items that you should consider monitoring.

Category Monitoring Stats
System Monitoring OS Stats, CPU, Memory, I/O
Network Bandwidth, connection speed
Server Processor(s) details.
Application Server Cluster, JMS Distributed Destinations, JDBC Connection Pool, Server Performance, Thread Pool
Java EE Application Cache Monitoring
Database Server Number of maximum and average DB connections, connection time.

The rest of this article discusses the details of object cache monitoring and the process of building a JMX implementation. JMX technology is gaining increasing attention in the area of application and server monitoring. JMX provides all the required tools for developing distributed, scalable, and modular solutions for managing and monitoring Java enterprise applications. JMX is based on MBeans (Managed Beans)—Java objects used for management needs—registered in a managed object server (an MBean Server), that acts as a management agent for monitoring purposes. You can use JMX monitoring locally or from a remote machine. Check out this article on how to remotely monitor a J2EE Cluster using Tomcat servers.

Here are the four main steps involved in a typical JMX implementation.

  1. Define an MBean interface
  2. Implement the interface on managed classes
  3. Register managed objects with an MBean server
  4. Monitor the objects using a JMX-compliant console
Object Cache Monitoring
Monitoring an object cache gives you insight into the details of the cache manages and stores objects, such as when objects are added to or removed from the cache. One important cache statistic is the hit-miss ratio, which is defined as the number of hits that successfully access data stored in the cache versus the number of misses. A "miss" occurs when the data isn't cached, and the application must access the data from the backend database—either because this is the first request for that data, or because the cached data has expired. The higher the hit-miss ratio, the better the objects are being managed in the cache; thus the hit-miss ratio is a good measure of the effectiveness of the object cache.

Aspect-oriented Programming
AOP lets you add design and run-time behavior to objects in a non-obtrusive way using static and dynamic cross-cutting. The main advantage of AOP is that you can write the code for cross-cutting concerns such as persistence or business rules using Aspects, and apply it declaratively (via Annotations or XML configuration) in the existing code. You can also dynamically inject the code into plain old Java objects (POJOs) for any third-party software components even if you don't have the source code or can't modify the code due to licensing restrictions. Using AOP you can design and implement Utility and Infrastructure modules that are completely separated from the core application logic. AOP offers a flexible and loosely coupled architecture as far as the application and infrastructure code are concerned. Areas in a typical Java EE application that can use Aspects are security, persistence, business, validation rules, and infrastructure code such as tracing, profiling, and performance management.

Monitoring and AOP
Monitoring is a good example of a cross-cutting concern. The integration of JMX and AOP provides a clean, centralized and reusable monitoring module in the application. You can dynamically add new monitoring capabilities in the application with minimal or no changes to the existing code. AOP provides the ability to enhance any part of the application with the code necessary to provide transparent application monitoring and management. You can define Aspects to monitor operations in the application and log the activity into MBeans to display monitoring information on a Web-based management console, all without touching any of the existing application code. You can also add support for notifications on property changes and registration with the MBean server.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date