Why does JMX open an additional two random ports? __jmx

Typically, the registry port is configured:

-dcom.sun.management.jmxremote.port=9123

The RMI server port can also be configured after JDK7 and can be configured to be the same.

-dcom.sun.management.jmxremote.rmi.port=9123

But there is also a random port not resolved ... Or is this buddy persistent, finally opened the bug
Http://stackoverflow.com/questions/20884353/why-java-opens-3-ports-when-jmx-is-configured



RELATED LINKS

https://issues.apache.org/bugzilla/show_bug.cgi?id=55931

Http://stackoverflow.com/questions/20699068/tomcat7-with-enabled-jmx-opens-2-additional-random-listening-ports
Http://tomcat.apache.org/tomcat-7.0-doc/config/listeners.html#JMX_Remote_Lifecycle_Listener_-_ Org.apache.catalina.mbeans.JmxRemoteLifecycleListener

-----------------------------------

JMX Port principle

http://chqz1987.blog.163.com/blog/static/5143831120131011105755778/

JMX connectivity through the firewall

Posted by Oleg Zhurakousky on March 23, 2009

Recently I ' ve been asked to help out a customer who is has issues with JMX connectivity to Spring Source dmserver thro Ugh the firewall. However, one thing I want to point out right up front are that the issue are rather generic and has nothing todo with Dmser Ver. It is really about understanding JMX, RMI and proper configuration. But I'll use the Dmserver and its configuration as a example.
This is the sample JMX configuration options provided in the Dmserver startup script:
-dcom.sun.management.jmxremote.port=${jmxport} \
-dcom.sun.management.jmxremote.authenticate \
-dcom.sun.management.jmxremote.password.file=${jmxuserspath} \
-djavax.net.ssl.keystore=${keystorepath} \
-djavax.net.ssl.keystorepassword=${keystorepassword} \
-dcom.sun.management.jmxremote.ssl=true \
-dcom.sun.management.jmxremote.ssl.need.client.auth=false "
This would enable the JMX agent (MBean Server) when you start Dmserver. Once started can now monitor your process via jmx-compliant tool such asJconsole. Connectivity could is local or remote.
The above configuration seem to provide everything we need to access this process through the firewall, sinceCom.sun.management.jmxremote.portis obviously the "port" we need to open in the firewall. However there is a caveat.
Once connected to Jmxregistry running on the port specified byCom.sun.management.jmxremote.portproperty, the actual objects are served by Rmiserver which was running on different port. Unfortunately this port is chosen randomly by default instance the JMX Agent and there is no–Doption to specify it. Obviously going through the firewall would require the opening up two ports and with random port it presents a delicate.
Fortunately it is easily solvable by writing a custom Java Agent where can programmatically specify each port and Exte Rnalize It through custom properties (I am attaching sample code).
More info here:http://java.sun.com/javase/6/docs/technotes/guides/management/agent.html
In the nutshell, the custom agent would take the port value provided by theCom.sun.management.jmxremote.portProperty and would create a second port (Rmiserver port) by the incrementing it by 1. The port specified is 44444 which makes Rmiserver port 44445)
Once such agent is in place (JAR) and the appropriate ports are open in the firewall all your need is modify the startup SC Ript to include–javaagent option providing the JAR.
. . . . .
$JAVA _home/bin/java \
-javaagent:/users/olegzhurakousky/.. /.. /.. /dmserver.jmx-0.0.1-snapshot.jar
$JAVA _opts \
. . . . .
So really only solved one half of the problem, since by default RMI stubs sent to the client contain the server ' s Private address instead of the public

Just tcpdump Fragment while monitoring the client ' s access (Jconsole running on the local network):
. . . . . . .
09:41:23.778663 IP 72.234.14.89.44444 > 192.168.1.156.52926:. ACK-win 65535 <nop,nop,timestamp 919359579 313492>
09:41:23.779958 IP 192.168.1.152.44444 > 72.234.14.89.52926:p 20:251 (231) Ack-win 65535 <nop,nop,timestamp 91935 9579 313492>
09:41:23.780456 IP 72.234.14.89.44444 > 192.168.1.156.52926:p 20:251 (231) Ack-win 65535 <nop,nop,timestamp 91935 9579 313492>
09:41:23.796075 IPs 192.168.1.156.37861 > 192.168.1.152.44445:s 1334070579:1334070579 (0) win 5840 <mss 1460,sackOK , timestamp 313496 0,nop,wscale 6>
09:41:23.796328 IP 192.168.1.152.44445 > 192.168.1.156.37861:s 1760846938:1760846938 (0) Ack 1334070580 win 65535 < MSS 1460,nop,wscale 3,nop,nop,timestamp 919359579 313496,sackok,eol>
. . . . . . .
You can clearly this 192.168.1.156 (client i.e., Jconsole) is attempting to connect directly to 192.168.1.152 (server) Instead of 72.234.14.89 which is a public IP, although the JMX URL is:
Service:jmx:rmi://72.234.14.89:44445/jndi/rmi://72.234.14.89:44444/jmxrmi

If I am behind the firewall I would obviously had problems connecting to 192.168.1.152
Fortunately, this one was easy to fix. All need are to provide additional option on the server side (Java.rmi.server.hostname"and add it to" script this option represents the host name string that should is associated with remote stubs for Loc Ally created remote objects, in order to allow clients to invoke methods on the remote object:
. . . . . . .
Jmx_opts= "\
$JMX _opts \
-dcom.sun.management.jmxremote.port=${jmxport} \
-djava.rmi.server.hostname=72.234.14.89 \
. . . . . . .
That's all.
Startjconsole:./jconsole.sh service:jmx:rmi://<pub-ip>:<rmi-port>/jndi/rmi://<pub-ip>:< Registry-port>/jmxrmi
Once you modify the script and start the dmserver you should the output similar to this:
. . . . . .
Oleg-2:bin olegzhurakousky$./startup.sh
com.springsource.rmiregistry.port:44444
com.springsource.rmiserver.port:44445
Getting the platform ' s MBean Server
Local Connection Url:service:jmx:rmi://oleg-2.local:44445/jndi/rmi://oleg-2.local:44444/jmxrmi
Public Connection Url:service:jmx:rmi://72.234.14.89:44445/jndi/rmi://72.234.14.89:44444/jmxrmi
Creating RMI Connector Server
[2009-02-26 18:53:34.031] main <SPKB0001I> Server starting.
[2009-02-26 18:53:35.943] main <SPOF0001I> OSGi telnet console available on port 2401.
[2009-02-26 18:53:41.558] main <SPKE0000I> Boot subsystems