Aop@work: Performance monitoring with ASPECTJ, part 2nd

Weaving using Glassbox Inspector by loading

Introduction: With a basic aspect-oriented monitoring infrastructure, you can extend it to meet real-world monitoring requirements. In the second part of this two-part article, Ron Bodkin shows how to add enterprise monitoring capabilities to the Glassbox Inspector, including monitoring multiple applications, Web services, and Web application frameworks. He also showed how to track application errors and include them in the monitoring code, and showed how to deploy and control the monitoring infrastructure programmatically.

The basic Glassbox Inspector I gave in the 1th part of this article can only monitor simple, Servlet-based applications (as in the case of Duke Bookstore), and a more systematic framework should include a framework for popular WEB applications such as S Truts and Spring) support. Today's WEB applications rarely use the Servlet to process requests directly. These frameworks typically delegate all dynamic page requests to the gateway Servlet, such as the dispatcherservlet of the Spring framework, and then delegate request processing to different controllers. Similarly, Struts Actionservlet is delegated to the Action subclass that acts as a controller.

In the second part of the article exploring performance monitoring with AspectJ, I extended the Glassbox Inspector to provide more meaningful information about application performance by adding monitors. These monitors track the interaction between the controllers of the Struts and Spring Web application frameworks and the response and request operations of the Web service. I also extended the system to support multiple applications, adding an error-handling layer and the ability to easily enable and disable monitoring at run time. At the end of the article, it shows how to weave the deployment Glassbox Inspector with the load, and how to measure the overhead.

To understand the examples in this article, there is a need for some understanding of Spring MVC, Struts, and the Apache Axis for Web Services. Glassbox Inspector The complete code for monitoring infrastructure see downloads. To download the ASPECTJ, JMX, and Tomcat 5 required to run the examples in this article, see Resources.

Reusable Operation Monitor

To get a broader range of monitoring capabilities, I put most of the reusable Servlet monitoring code in Listing 5 of part 1th in the abstractoperationmonitor aspect. In many cases, it is important to keep track of nested requests, including the ability to track controllers at different levels of the framework and to track requests for delegation, such as from forwarding to nested requests. Listing 1 shows how I extend the Glassbox Inspector to track nested requests for operations:

Listing 1. Reusable operational monitoring aspects

Public abstract Aspect Abstractoperationmonitor extends Abstractrequestmonitor {

Protected abstract class Operationrequestcontext extends RequestContext {
/**
* Find the appropriate statistics collector object for this
* operation.
* @param operation An instance of the operation being
* Monitored
*/
Public PerfStats Lookupstats () {
if (getparent ()!= null) {
Nested operation
Operationstats parentstats =
(operationstats) GetParent (). GetStats ();
Return Parentstats.getoperationstats (Getkey ());
}
Return Gettoplevelstats (Getkey ());
}

/**
* Determine the top-level statistics for a given operation
* Key. This also looks up the "context" name for the
* Application from the Operation Monitor:
* @see Abstractoperationmonitor#getcontextname (Object)
* For a WEB application, top-level statistics are normally
* All Servlets, and the key is the Servlet name.
* @param key an object to uniquely identify the
* Operation being performed.
*/
Protected Operationstats gettoplevelstats (Object key) {
Operationstats stats;
Synchronized (topleveloperations) {
Stats = (operationstats) topleveloperations.get (key);
if (stats = = null) {
Stats =
Perfstatsfactory.createtopleveloperationstats (Key,
Getcontextname (Controller));
Topleveloperations.put (key, stats);
}
}
return stats;
}

/**
* @return An object that uniquely identifies the operation
* being performed.
*/
Protected abstract Object getkey ();

/** the current controller object executing, if any. */
protected Object Controller;
};
/**
* This advice stores the Controller object whenever we construct a
* Request context.
*/
After (Object Controller) returning (Operationrequestcontext ctxt):
Cflow (adviceexecution () && args (Controller, ...) &&
This (abstractoperationmonitor)) &&
Call (Operationrequestcontext+.new (..)) {
Ctxt.controller = Controller;
}
...