geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dain Sundstrom (JIRA)" <>
Subject [jira] Updated: (GERONIMO-663) Request to improve Geronimo's JMX support for remote management systems
Date Sat, 10 Dec 2005 00:27:09 GMT
     [ ]

Dain Sundstrom updated GERONIMO-663:

    Fix Version: Wish List
                     (was: 1.0)

I agree with everything you have written, but it will be a while before we can change every
service to follow the best practices you have laid out.

Can you add this to the wiki as JMX best practices? 

> Request to improve Geronimo's JMX support for  remote management systems
> ------------------------------------------------------------------------
>          Key: GERONIMO-663
>          URL:
>      Project: Geronimo
>         Type: Improvement
>   Components: general
>     Versions: 1.0-M4
>     Reporter: Sing Li
>     Priority: Minor
>      Fix For: Wish List

> The remote JMX support on Geronimo works amazing well.
> Because of this, it also painfully reveals the tightly 
> coupled heritage between Geronimo core and local
> JMX based management/debugging tools.
> Unfortunately, this is not good for remote management.
> In particular, consider the topology where a bank of 
> Geronimo servers may be managed via a single 
> third-party management console. The same console 
> may also manage a large number of non-Geronimo 
> servers and assorted hardware. In order to "fit in" , 
> the attributes and operations exposed through Geronimo 
> should conform to the capability of the 
> system.
> The following are some suggestions/guidelines that can 
> make the server more friendly to remote JMX management 
> systems.
> 1. Attributes with primitive types such as int, long, boolean, etc. 
> should be exposed via their wrappers Integer, Long, Boolean, etc. 
> In general, for maximal compatibility with remote JMX management 
> systems, expose attributes with only the types described in the JDK 5
> javadoc for
> ---------------------------------------------------------
> 2.  Attributes with custom Geronimo specific-type should not be exposed. 
>  Currently, there are attributes with type as complex as:
>   org.apache.geronimo.kernel.Kernel
>   org.apache.geronimo.gbean.GBeanLifecycleController
>   org.apache.geronimo.kernel.DependencyManager
> Remote JMX systems may need the entire Geronimo build 
> to resolve all of the inter-dependencies; even if they
> manage to do this, they will not know what is meaningful
> to display to the management user for these attributes.
> Such attribute is better exposed as a String typed 
> attribute that summarize its current state or value.
> ----------------------------------------------------------
> 3. Attributes that are intrinsically date values should be exposed as Date, 
> and not as Long (or worse, long).
> 4. There are many attributes (such as classPath and dependencies) that are exposed 
> currently as either java.util.List, java.util.URL, or  These should be
> as a simple String attribute that concatenate or pre-format the relevant information.
> 5. Last but not least, there exists almost no exposed attribute that changes dynamically

> in value with time. 
> This is unusual, because such intrumentation is frequently used in trouble-shooting and

> performance tuning of servers. 
> Instead of using alternate means, one may want to consider exposing them through 
> JMX - and viewing the status via remote consoles, stats aggregators, etc.
> The highly desirable side-effect of exposing these meterics is that they will 
> immediately provide a "visual face" for Geronimo, over and above the current 
> festive rainbow feather.
> Network Management System users will be able to immediately
> wire up beautiful gauges, meters, pie charts, dancing grids,
> and rotating 3-D balls to these exposed metrics... indirectly
> helping to promote the server... right alongside the buzzing 
> Weblogic/Websphere/JBoss dashboards :-)
> PS... The components in the Tomcat 5 server have 
> been thoroughly instrumented for remote JMX, but 
> it seems that none of the metrics is exposed 
> through Geronimo at this time :-(

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message