You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Ole Gunnar Borstad <ol...@stud.ntnu.no> on 2007/07/10 15:54:35 UTC
JMX-management and monitoring
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
Re: JMX-management and monitoring
Posted by David Van Couvering <da...@vancouvering.com>.
This sounds good, Ole, I look forward to seeing your work. It would
be nice to integrate the JMX support into NetBeans after it becomes
available. I like the idea of creating an MBean for
NetworkServerControl.
I saw your query about default properties, BTW, but remained silent
because I don't have an answer and don't have the time right now to
research it. Perhaps you could explain what you're trying to
accomplish, and maybe there are other ways to accomplish it?
David
On 7/11/07, Ole Gunnar Borstad <ol...@stud.ntnu.no> wrote:
> Thanks for your reply, David. To clarify, Apache Commons is currently
> used to ease the implementation of *Model MBeans*, which is a generic
> Dynamic Bean. This means that a generic bean is paired
> programmatically with the resource it is going to manage. This is in
> contrast to coding a specific bean for a resource. We can still use
> Dynamic MBeans even if we base the majority of the beans on standard
> ones.
>
> The plan for my work now is somewhat like this (in agreement with my
> mentor Bernt Johnsen):
>
> 1. Refactor the current functionality to Standard MBeans:
> - Stopping a database (not the derby server)
> - Viewing and modifying some Derby properties
>
> 2. Expand the properties functionality. Currently this is very limited.
>
> 3. Create an MBean for NetworkServerControl, essentially making the
> API available through a management interface.
>
> I hope this will give a good start on Derby management and monitoring,
> at least give something to work on further and produce some discussion
> on user/developer needs. I welcome suggestions and thoughts!
>
> Ole Gunnar
>
> Siterer David Van Couvering <da...@vancouvering.com>:
>
> > 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 <ol...@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
> >>
> >>
>
>
>
>
Re: JMX-management and monitoring
Posted by Ole Gunnar Borstad <ol...@stud.ntnu.no>.
Thanks for your reply, David. To clarify, Apache Commons is currently
used to ease the implementation of *Model MBeans*, which is a generic
Dynamic Bean. This means that a generic bean is paired
programmatically with the resource it is going to manage. This is in
contrast to coding a specific bean for a resource. We can still use
Dynamic MBeans even if we base the majority of the beans on standard
ones.
The plan for my work now is somewhat like this (in agreement with my
mentor Bernt Johnsen):
1. Refactor the current functionality to Standard MBeans:
- Stopping a database (not the derby server)
- Viewing and modifying some Derby properties
2. Expand the properties functionality. Currently this is very limited.
3. Create an MBean for NetworkServerControl, essentially making the
API available through a management interface.
I hope this will give a good start on Derby management and monitoring,
at least give something to work on further and produce some discussion
on user/developer needs. I welcome suggestions and thoughts!
Ole Gunnar
Siterer David Van Couvering <da...@vancouvering.com>:
> 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 <ol...@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
>>
>>
Re: JMX-management and monitoring
Posted by David Van Couvering <da...@vancouvering.com>.
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 <ol...@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
>
>