Cannot connect to Tomcat's MBeanServer via jconsole in Java6

Question

I'm on a vista machine. I've started tomcat 5.5.27 with these options:

CATALINA_OPTS="-Dcom.sun.management.jmxremote.port=9003 \
    -Dcom.sun.management.jmxremote.ssl=false \
    -Dcom.sun.management.jmxremote.authenticate=false"

When I connect via jconsole and added the following service url

service:jmx:rmi:///jndi/rmi://localhost:9003/jmxrmi

it would not connect. Any ideas ?

Solution 1

Ok, I orignally supposed the URL given by op was wrong but it turns out no. So I can't answer.

Still, here are the basics:

For a simple connection through jconsole.

If you know that the JMX Server you want to connect to has the RMI registry port at 9003 for example, connect using

localhost:9003

instead.

Otherwise, here's what I found out from the ground up:

Suppose you have the JMX Server (alias 'JMX Agent' alias 'the JVM you want to connect to') running on 'TARGET MACHINE' with the RMI registry port at 'RMI REGISTRY PORT' and the JMX RMI server port at 'JMX RMI SERVER PORT'.

Note:

1. The RMI registry tells JMX clients where to find the JMX RMI server port; information can be obtained under key jmxrmi.
2. The RMI registry port is generally known as it is set through system properties at JVM startup.
3. The JMX RMI server port is generally not known as the JVM chooses it at random (if no other precautions are taken).

The following URI will lead to success (tested)

service:jmx:rmi://<TARGET_MACHINE>:<JMX_RMI_SERVER_PORT>/jndi/rmi://<TARGET_MACHINE>:<RMI_REGISTRY_PORT>/jmxrmi

This looks nasty. Let's cut it apart.

This URI is an RFC2609 "Service Location Protocol URL" (well, it's really an URI, right?)

It is composed of:

• service - a constant
• jmx:rmi - the service type composed of: abstract type jmx and URL scheme rmi
• the rest - the sap (service access protocol specification)

sap is decomposed into:

• //<TARGET_MACHINE>:<JMX_RMI_SERVER_PORT> - ipsite
• /jndi/rmi://<TARGET_MACHINE>:<RMI_REGISTRY_PORT>/jmxrmi - URL part

A well-informed JMX client connects to the "ipsite" to do JMX-over-RMI exchanges; but what of the JMX client that doesn't KNOW that port? Patience...

URL part is decomposed into:

• /jndi/ - This seems to tell the JMX client that it can get lookup information at the location that follows
• rmi://<TARGET_MACHINE>:<RMI_REGISTRY_PORT>/jmxrmi - Yep, we get information about the JMX RMI Server at the RMI registry, under the lookup key jmxrmi

This is somewhat cart-before-horse, as one has to contact the RMI registry given by the latter part of the SLP URL first.

After scratching head, intuitively, let's try:

service:jmx:rmi://<TARGET_MACHINE>/jndi/rmi://<TARGET_MACHINE>:<RMI_REGISTRY_PORT>/jmxrmi

Yes, that works! The JMX RMI server port is nicely obtained from the registry. On second thoughts, the target machine should also be obtained from the registry, thus:

service:jmx:rmi:///jndi/rmi://<TARGET_MACHINE>:<RMI_REGISTRY_PORT>/jmxrmi

Even better, that works, too!

References:

1 download.oracle.com/javase/6/docs/api/javax/management/remote/rmi/package-summary.html
2 download.oracle.com/javase/6/docs/api/javax/management/remote/JMXServiceURL.html
3 mx4j.sourceforge.net/docs/ch03s04.html
4 download.oracle.com/javase/6/docs/technotes/guides/management/agent.html#gdevg
5 http://www.rfc-editor.org/rfc/rfc2609.txt

Solution 2

On Ubuntu 10.04, using OpenJDK 6 and Tomcat 6.0.29, I was unable to activate JMX for a local jconsole session, no matter how many com.sun.management.jmxremote.* options I passed to java with CATALINA_OPTS. The problem was the -Djava.io.tmpdir setting, which defaults to $CATALINA_BASE/temp. I simply had to set:

CATALINA_TMPDIR="/tmp"

at the beginning of bin/catalina.sh and I was able to connect locally with jconsole, jmap, jps etc. There was no need for any com.sun.management.jmxremote.* settings at all.

Solution 3

Are the processes run under the same user?

You can also check by running jps and jconsole (both in the JDK_HOME/bin directory)

Comments

[Paul]

This did not work for me, i still receive the same error. In any case, glad it helped you, but I am wondering the intuition behind why this works. Perhaps this idea can be extended...