Skip to main content

Excellent article by Ron Bodkin about using AspectJ and JMX technologies for monitoring

Posted by emcmanus on November 5, 2005 at 5:53 AM PST

Ron Bodkin has written an excellent, detailed

article
about using the
Glassbox
Inspector
project. This combines AspectJ and JMX
technologies to add monitoring to applications in a clean and
modular way.

I particularly like this style of article, where extended code
extracts are used to present something really useful rather than
just a toy example. The alternating text and code reminds me of
Literate
Programming
.

While

much has been written
about the possible abuses of AOP,
most of it focuses on cases where AOP is used to change the
visible semantics of a program, so what you see is not
what you get. Most people agree that using
AOP to add monitoring or logging to a program is an excellent
fit (with the usual warning to beware of performance impact).
This article shows how this can be done cleanly and
transparently. It provides one good answer to a question that
often arises about using JMX technology: how do you link the
application's objects to the JMX instrumentation without
breaking modularity? You don't want to hardwire JMX API
references into application classes, and you don't want your JMX
MBeans to be reaching into the innards of your application to
pick out the objects they need. (There are other good answers
too, by the way.)

Having said all that, I did have a few issues with the
article. There are some minor inaccuracies in the code
extracts, though I dare say that can easily be fixed. The
advice to use Model MBeans rather than Standard MBeans, because
of inheritance problems with the latter, seems to ignore the
class

javax.management.StandardMBean
. I find that
most cases where you might want to use Dynamic MBeans (of which
Model MBeans are a kind) can more simply be coded using this
class or a custom subclass.

The

advice
about ignoring thread safety is somewhat dangerous.
While it is true that concurrent updates to statistics are
typically rare, the
Java Memory Model
basically allows a thread to hold on to
its private copy of a field for as long as it likes provided
there's no synchronization. So with an aggressively-optimizing
system you could find that each thread was maintaining its own
copy of a supposedly-common set of statistics. The values you
would observe would be essentially random. If you don't want to
pay the penalty of synchronizing across a read-modify-write
(like counter++ or whatever), but you also don't want to run the risk
of the random behaviour I just mentioned, then declaring fields
volatile is a good compromise. This can still give wrong
results in the face of two concurrent read-modify-writes but as
Ron says this is likely to be too rare to make any significant
difference to the statistics.

Anyway, Ron finishes this Part 1 with this striking screenshot
where the humble JConsole is used to present some very useful
information. I'll be looking forward to Part 2!

src="http://www-128.ibm.com/developerworks/java/library/j-aopwork10/Figure5.jpg"
alt="JConsole screenshot showing Glassbox instrumentation">

Related Topics >>