You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Sing Li (JIRA)" <de...@geronimo.apache.org> on 2005/06/05 20:58:41 UTC
[jira] Updated: (GERONIMO-663) Request to improve Geronimo's JMX support for remote management systems
[ http://issues.apache.org/jira/browse/GERONIMO-663?page=all ]
Sing Li updated GERONIMO-663:
-----------------------------
Description:
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 javax.management.openmbean.SimpleType.
---------------------------------------------------------
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 java.net.URI. These should be exposed
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 :-(
was:
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 javax.management.openmbean.SimpleType.
---------------------------------------------------------
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 java.net.URI. These should be exposed
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 has
been thoroughly instrumented for remote JMX, but
it seems that none of the metrics is exposed
through Geronimo at this time :-(
> Request to improve Geronimo's JMX support for remote management systems
> ------------------------------------------------------------------------
>
> Key: GERONIMO-663
> URL: http://issues.apache.org/jira/browse/GERONIMO-663
> Project: Geronimo
> Type: Improvement
> Components: general
> Versions: 1.0-M4
> Reporter: Sing Li
> Priority: Minor
>
> 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 javax.management.openmbean.SimpleType.
> ---------------------------------------------------------
> 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 java.net.URI. These should be exposed
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira