Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Message-ID: <382000971.1117997921151.JavaMail.jira@ajax.apache.org>
Date: Sun, 5 Jun 2005 20:58:41 +0200 (CEST)
From: "Sing Li (JIRA)" <dev@geronimo.apache.org>
To: dev@geronimo.apache.org
Subject: [jira] Updated: (GERONIMO-663) Request to improve Geronimo's JMX
 support for  remote management systems
In-Reply-To: <1523736562.1117997920419.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ 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