Hi,
I am working on management and monitoring through JMX in Derby. Prior
work on this includes a patch in Derby-1387 that has some working
functionality, i.e. viewing properties and shutting down a single
database. I think this patch shows great potential for management
features in Derby. The code uses the Apache Commons Modeler framework
for defining Model MBeans, because developing these Beans completely
manually is rather cumbersome and error prone. Model MBeans are the
most flexible MBeans through the use of several metadata classes,
which enables the managed resource and management interface to be
specified at runtime.
Upon further development of this module, I have tried to analyze the
choice of MBeans for Derby. The use of different types of MBeans can
of course be combined, but if there is no real need for the generic
nature of Model MBeans, it might be a better choice to go with
Standard MBeans as the main choice and not depend on any framework
like Commons. This framework implies two additional JARs for Derby and
increasing code complexity through XML-metadata and API-dependencies.
The advantage of using this configuration is that existing resources
can easily be instrumented for management through an XML-metadata
file. I am not sure if this is true for Derby, because the resources
can not always be instrumented automatically. An example is the Derby
properties. These do not have a coherent access interface (depends on
how properties are set or if defaults are used), so making
getter-methods for these in a management module is not trival and
should be done by hand.
The advantages of using Model MBeans and thus a framework like Commons
seem unclear to me at this point. Coding Standard or Dynamic MBeans
can be done efficiently without tools, and as far as I can see they
are more than powerful enough for management of Derby.
I would appreciate any input on this matter, especially from someone
with experience using JMX.
Ole Gunnar Borstad
- JMX-management and monitoring Ole Gunnar Borstad
-