Bug 590175 - Feature request: Enhance plugin 'JMX' to discover local-access MBeanServers
Feature request: Enhance plugin 'JMX' to discover local-access MBeanServers
Status: CLOSED DEFERRED
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
1.3.1
All Linux
low Severity low (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Corey Welton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-07 18:01 EDT by Gordon Daugherty
Modified: 2010-05-10 14:50 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-10 14:50:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gordon Daugherty 2010-05-07 18:01:06 EDT
Description of the feature requested:

Enhance the 'JMX' plugin to be able to discover MBeanServers that are not remote-accessible.  I'd like to use JOPR to monitor many standalone JVMs whose MBeanServers are configured to only be accessible locally.

This will eliminate the need to secure each of those MBeanServers and will have the side benefit that teams won't have MBeanServer remote port # collisions.  

In order for this to work we'll have to run the Agent as the same userid as the processes to be monitored.

The existing 'JMX' plugin discovers MBeanServers running on the same machine as the agent by looking at the process list for the following argument:
  -Dcom.sun.management.jmxremote.port=portNum

This works when the JVM to be monitored exposes its MBeanServer on a remote access port (as described here: http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html#remote).

JVMs that are not configured to expose their MBeanServer(s) on a remote port may still be accessed from that local machine by a process that is run as the same userid.  This can be demonstrated using JConsole.  The method of discovery required is slightly different in that you can't just look for the port number argument described above.

Version-Release number of selected component (if applicable):

rhq-jmx-plugin 1.3.0.GA

Additional info:

I have a rough version of an extension to the JMX plugin that demonstrates this functionality.  I'll attach that sometime in the next couple of days.
Comment 1 Gordon Daugherty 2010-05-10 14:46:43 EDT
Oops - I just discovered that the JMX plugin developers have already been down this road.  I just encountered the same drawback that is described in the disabled section of code cited below.

In JMXDiscoveryComponent.java:
// This model of discovery is of questionable usefulness since if you restart your process you'll get a new resource
// Works only on JDK6 and maybe some 64 bit JDK5 See JBNADM-3332.

Link to source:
http://svn.rhq-project.org/repos/rhq/trunk/modules/plugins/jmx/src/main/java/org/rhq/plugins/jmx/JMXDiscoveryComponent.java
Comment 2 Gordon Daugherty 2010-05-10 14:50:37 EDT
Closing ticket.  Unless we can come up with a way to deal with the fact that the JMX URL is different after a process restarts this is of limited usefulness.  We don't want to have to re-discover and re-import a process each time that it is restarted.

Note You need to log in before you can comment on or make changes to this bug.