JAMon can be used to determine application performance bottlenecks, user/application interactions, and application scalability. JAMon gathers summary statistics such as hits, execution times (total, average, minimum, maximum, standard deviation), simultaneous application requests and more. JAMon statistics are displayed in the JAMon report.
JAMon was developed primarily for monitoring J2EE applications, however it can be used in any JDK 1.2 or higher environment. JAMon can be used in Servlets, JSP's, EJB's and Java Beans in various J2EE Application Servers (Sybase's EAServer, and BEA's WebLogic,…), and can also be used in other programming environments that can call Java code (ColdFusion, PowerBuilder, BroadVision, ...).
JAMon Implementation details
The implementation of JAMon uses several design patterns from the book "Design Patterns Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. A number of the creational patterns are used to create monitors. The convention is that any class involved in the creation of monitors has the word Factory in its name. Other patterns such as the decorator, and composite patterns are also used.
Despite JAMon's relatively high number of classes, in most cases the only methods that are required to begin monitoring are MonitorFactory.add(...), MonitorFactory.start(…), Monitor.stop(), and MonitorFactory.getReport(). Most of JAMon's classes are pretty simple.
"TestClass" has sample invocations of JAMon code. I run the TestClass's main() method whenever code changes are made to ensure that errors weren't introduced. "TestClassPerformance" has various performance tests.
The decorator pattern dominates the design of JAMon. The decorator pattern is a way to chain objects with the same interface (Monitor), but different responsibilities.
When a method such as start(...) is called on the first Monitor in the chain it performs its work and calls the start(...) method on the next Monitor in the chain. The classes referenced in this decorator chain are the most important in JAMon and are responsible for tracking all JAMon statistics.
The outer most Monitor returned to the client in the decorator chain (for Timing Monitors) is unique per invocation of the start(...) method. All of the other Monitors in the chain gather summary statistics and are shared by every invocation of MonitorFactory.start(...) that is passed the same label. Because multiple threads may simultaneously attempt to update the summary statistics, Monitors are thread safe.
JAMon makes extensive use of HashMaps in storing Monitors. The label passed to "MonitorFactory.start("myMonitorLabel");" is the key to the HashMap and Monitors are the values.
JAMon consumes very few resources and is fast. On a 2 GHz Pentium IV, start() and stop() were were called 625,000 times in 1 second! JAMon can also be disabled at runtime to even further minimize impact on application performance.
JAMon follows a few conventions:
For further information on JAMon look at the JAMon user's manual at www.jamonapi.com or review the source code which is also available via this site.
Steve Souza - admin@jamonapi.com (JAMon v1.0)