How to remotely connect to jmx on tomcat using ssh tunnelling and not break ehcache...

Question

I've followed the instructions in the following link to create my own RMI registry and jmx server on a single port inside tomcat. According to the comments, I need to set -Djava.rmi.server.hostname=localhost. Once I do that, I can indeed connect to my server via jconsole using ssh port forwarding.

http://blogs.sun.com/jmxetc/entry/connecting_through_firewall_using_jmx

However, I've found it has the very bad side affect of breaking our ehcache replication which uses RMI. It fails complaining that it cannot bootstrap from remote peer localhost. I'm guessing because the peers all have their rmi server hostname set to localhost from setting -Djava.rmi.server.hostname=localhost.

Does anyone have a possible workaround to this problem?

Answer 1

I just came across the problem. The problem is that the java.rmi.servername.hostname property is global. To make ehcache and the jmx server play in harmony, you must perform a few hacks on the machine you're running VisualVM from.

Here's what you need to do. This is based on using a Mac for the client so modify the commands as needed.

1. Remove the -Djava.rmi.server.hostname=localhost.

2. Write a tester application that will give you the value of InetAddress.getLocalHost().getHostAddress() on your server machine you want to profile. This should give you the local ip (private if nat'd). You will have to refer to this IP on your local machine. Use this IP where the commands below say IP.

3. Now, this is the fun part: Add the internal IP to your loopback interface on your machine. (ifconfig lo0 IP netmask 255.255.255.0 up)

4. Test that this will actually direct traffic to the loopback. It should return the loopback. (route get IP)

5. Initiate the SSH tunnel: ssh -C -L IP:PORT:localhost:PORT -L IP:OTHER_PORT:localhost:OTHER_PORT user@host.

Notice the IP's for the ssh tunnel are actually the one now tied to loopback. You no longer refer to localhost, but the IP of the machine for everything. You'll also have to modify your JMX URL to refer to this IP instead of localhost.

Answer 2

If you look for an easy to use, firewall friendly JMX remoting alternative, jmx4perl might be worth a try. It is an agent based approach, which export JMX MBeans via HTTP/Rest.

Though its main focus is directed for use in a scripting environment (i.e. perl) for monitoring purposes, for the scheduled version 0.70 a Java client library has been added (beta quality)