db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering" <da...@vancouvering.com>
Subject Re: JMX-management and monitoring
Date Tue, 10 Jul 2007 20:05:23 GMT
Hi, Ole.  Your analysis seems reasonable.  The management requirements
for Derby are pretty minimal and pretty static, and it is always good
to keep things as simple as possible for Derby, both for development
and distribution/deployment.  Adding more jar files also increases the
size.  I didn't know the use of Dynamic MBeans required the Apache
Commons stuff, or if that was just a quick way of implementing the
functionality.  But if we don't need dynamic beans, let's keep it
simple.

David

On 7/10/07, Ole Gunnar Borstad <olegunb@stud.ntnu.no> wrote:
> 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
>
>

Mime
View raw message