Why Java Opens 3 Ports When Jmx Is Configured

Why Java opens 3 ports when JMX is configured?

Contrary to common belief JMX/RMI doesn't need to open all these ports. You can actually force them to be same which will mean that at the end of the day you'll only need to punch one hole in the firewall (if firewall is your concern).

Try setting System Properties:

com.sun.management.jmxremote.port
com.sun.management.jmxremote.rmi.port

to the same value!!

Explicitly setting these will stop RMI from picking random ports. Setting them to the same value will make sure it opens less ports to listen on.

This will work in Java 7 update 25 or later.

What is the third port?

The third port that you see opened by your application (or the second if you followed my advice above) is used by the Java Attach API. It is what JConsole uses for connecting to "Local Process". The Java Attach API feature is enabled by default since Java 6 regardless of the com.sun.management.jmxremote property. This feature will use a random port (aka an OS ephemeral port) but it really doesn't matter because the feature only allows connections from the host itself. If you really dislike this feature then you can add -XX:+DisableAttachMechanism to the command line to disable the Java Attach API feature. Then you'll no longer see the java process (in this case Tomcat) listening on a random port.

How do I make JMX listen on the loopback interface only

With a custom made application you would use a RMIServerSocketFactory but this is Tomcat so you would have to do it using Tomcat's JMX Remote Lifecycle Listener.

On the other hand it doesn't matter now that you have the com.sun.management.jmxremote.local.only property since Java 7. It makes sure that only connections from the host itself are allowed. Mind you that JMX library doesn't achieve this by binding to loopback interface which would certainly be one way of doing it but also slight inaccurate as a host can potentially have several loopback interfaces.

In fact by and large (with the most recent additions to JDK wrt JMX) I would say that Tomcat's JMX Remote Lifecycle Listener is now redundant except if you want to bind to some really odd network interface.

JMX enabled Java application appears to open a random high order port when JMX client connects

It's possible to control the port used by RMI. See: http://olegz.wordpress.com/2009/03/23/jmx-connectivity-through-the-firewall/

This requires code and a command-line parameter. There's no way that I know of to do this without code (though the code can obviously be packaged in a different jar).

Tomcat7 with enabled JMX opens 2 additional random listening ports

You can use Tomcat's JMX Remote Lifecycle Listener which allows fixing the ports used by the JMX/RMI Server.

The JMX Remote Lifecycle Listener allows configuring the following ports:

• rmiRegistryPortPlatform - The port to be used by the JMX/RMI registry
  for the Platform MBeans. This one should be used instead of the com.sun.management.jmxremote.port system property
• rmiServerPortPlatform - The port to be used
  by the Platform JMX/RMI server.

In addtions you can configure the useLocalPorts attribute - Should any clients using these ports be forced to use local ports to connect to the the JMX/RMI server.

Notice that this listener requires catalina-jmx-remote.jar to be placed in $CATALINA_HOME/lib. This jar may be found in the extras directory of the binary download area.

Does Java 6 open a default port for JMX remote connections?

The documentation suggests that the JMX agent uses a local port -- something unreachable from outside the machine -- unless you specify the following property:

com.sun.management.jmxremote.port=portNum

This is for security reasons, as well as for the reason given by Mr Potato Head. Thus, it looks like Java 6 does not open a default remotely accessible port for JMX.

EDIT: Added after the OP added an answer with more information.

Another option you have is to somehow create a local proxy that listens to all local JMX connections and exports this information. This way, you don't need to have such magic configuration of each JVM instance on the server. Instead the local proxy can connect to all JVMs via JMX and then somehow expose this information remotely. I am not positive exactly how you would implement this, but something like this may be less work than what you otherwise have to do to expose all of your JVMs remotely via JMX.

---

Related Topics