Pourquoi Java ouvre 3 ports quand JMX est configuré?
j'exécute mon programme Java avec JDK7 sur Centos6. J'active JMX en utilisant les options suivantes:
JAVA_OPTS="${JAVA_OPTS} -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9123 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.local.only=true"
quand je vérifie quels ports sont ouverts, je découvre 2 ports aléatoires supplémentaires:
netstat -plunt | grep java
tcp 0 0 :::9123 :::* LISTEN 13295/java
tcp 0 0 :::59927 :::* LISTEN 13295/java
tcp 0 0 :::59928 :::* LISTEN 13295/java
veuillez noter que chaque redémarrage du port 9123 reste le même et que deux ports supplémentaires changent les valeurs.
netstat -plunt | grep java
tcp 0 0 :::9123 :::* LISTEN 13331/java
tcp 0 0 :::59932 :::* LISTEN 13331/java
tcp 0 0 :::59933 :::* LISTEN 13331/java
que sont 2 ports supplémentaires et pourquoi ils sont ouverts?
comment configurer 2 ports aléatoires supplémentaires?
comment configurer ::ffff:127.0.0.1 apparaîtra avant tous les ports ouverts par JMX?
pourquoi un port n'est pas utilisé lors de la connexion avec JConsole?
ajouté pour clarifier la réponse
malheureusement, le port aléatoire supplémentaire est toujours ouvert Pour vous rappeler, J'utilise Centos 6. Mes paramètres Tomcat ressemblent à ceci (Tomcat ne déploie aucune application):
CATALINA_OPTS="${CATALINA_OPTS} -XX:+DisableAttachMechanism -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.local.only=true -Djava.rmi.server.useLocalHostname=true -Djava.rmi.server.useCodebaseOnly=true -Dcom.sun.management.jmxremote.port=9123 -Dcom.sun.management.jmxremote.rmi.port=9123"
Tomcat process ressemble à ceci:
/usr/java/jdk1.7.0_51/bin/java -Djava.util.logging.config.file=/usr/tomcat-7.0.47/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -XX:+DisableAttachMechanism -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.local.only=true -Djava.rmi.server.useLocalHostname=true -Djava.rmi.server.useCodebaseOnly=true -Dcom.sun.management.jmxremote.port=9123 -Dcom.sun.management.jmxremote.rmi.port=9123 -Djava.endorsed.dirs=/usr/tomcat-7.0.47/endorsed -classpath /usr/tomcat-7.0.47/bin/bootstrap.jar:/usr/tomcat-7.0.47/bin/tomcat-juli.jar -Dcatalina.base=/usr/tomcat-7.0.47 -Dcatalina.home=/usr/tomcat-7.0.47 -Djava.io.tmpdir=/usr/tomcat-7.0.47/temp org.apache.catalina.startup.Bootstrap start
malheureusement, chaque fois que je vois un port d'écoute supplémentaire:
tcp 0 0 :::38830 :::* LISTEN 790/java
tcp 0 0 ::ffff:127.0.0.1:8080 :::* LISTEN 790/java
tcp 0 0 :::9123 :::* LISTEN 790/java
course supplémentaire:
tcp 0 0 ::ffff:127.0.0.1:8080 :::* LISTEN 2348/java
tcp 0 0 :::36252 :::* LISTEN 2348/java
tcp 0 0 :::9123 :::* LISTEN 2348/java
BTW, pourquoi je ne peux pas voir ::ffff:127.0.0.1 avant les ports RMI?
ajouté une deuxième fois pour clarifier le commentaire
Il n'est pas lié à Tomcat. J'ai essayé d'exécuter ant avec les mêmes paramètres: Processus Ant ressemble à ceci:
/usr/bin/java -XX:+DisableAttachMechanism -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.local.only=true -Djava.rmi.server.useLocalHostname=true -Djava.rmi.server.useCodebaseOnly=true -Dcom.sun.management.jmxremote.port=9123 -Dcom.sun.management.jmxremote.rmi.port=9123 -classpath /usr/apache-ant-1.9.2/lib/ant-launcher.jar -Dant.home=/usr/apache-ant-1.9.2 -Dant.library.dir=/usr/apache-ant-1.9.2/lib org.apache.tools.ant.launch.Launcher -cp sleep
malheureusement, chaque fois que je vois un port d'écoute supplémentaire:
tcp 0 0 :::41200 :::* LISTEN 13597/java
tcp 0 0 :::9123 :::* LISTEN 13597/java
course supplémentaire:
tcp 0 0 :::58356 :::* LISTEN 13629/java
tcp 0 0 :::9123 :::* LISTEN 13629/java
réponse: c'est le bug de Java
j'ai réussi à ouvrir un bug sur Java: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8035404
4 réponses
contrairement à la croyance courante, JMX/RMI n'a pas besoin d'ouvrir tous ces ports. Vous pouvez réellement forcer à être même, ce qui signifie qu'à la fin de la journée, vous aurez seulement besoin d'percez un trou dans le pare-feu (si le pare-feu est votre préoccupation).
essayer de définir les propriétés du système:
com.sun.management.jmxremote.port
com.sun.management.jmxremote.rmi.port
à la même valeur!!
les définir explicitement empêchera RMI de choisir des ports aléatoires. À la même valeur assurez-vous qu'il ouvre moins de ports à écouter.
cela fonctionnera dans Java 7 update 25 ou plus tard.
Qu'est-ce que le troisième port?
le troisième port que vous voyez ouvert par votre application (ou le deuxième Si vous avez suivi mon conseil ci-dessus) est utilisé par Java Attach API . C'est ce que JConsole utilise pour se connecter au "processus Local". La fonctionnalité Java Attach API est activée par défaut depuis Java 6 indépendamment de la propriété com.sun.management.jmxremote . Cette fonctionnalité utilisera un port aléatoire mais cela n'a pas vraiment d'importance parce que la fonctionnalité n'autorise que les connexions à partir de l'hôte lui-même. Si vous n'aimez pas vraiment cette fonctionnalité, vous pouvez ajouter -XX:+DisableAttachMechanism à la ligne de commande pour désactiver la fonctionnalité Java Attach API. Vous ne verrez plus le processus java (dans ce cas Tomcat) écouter sur un port aléatoire.
Comment puis-je faire JMX écouter sur l'interface de bouclage seulement
avec un application personnalisée vous utiliseriez un RMIServerSocketFactory mais C'est Tomcat donc vous auriez à le faire en utilisant Tomcat's JMX distant Lifecycle Listener .
d'un autre côté, cela n'a plus d'importance maintenant que vous avez la propriété com.sun.management.jmxremote.local.only depuis Java 7. Il s'assure que seules les connexions de l'hôte lui-même sont autorisées. Remarquez que la bibliothèque JMX n'y parvient pas en se liant à l'interface loopback qui certainement un façon de faire, mais aussi légèrement inexacte comme un hôte peut avoir plusieurs interfaces de bouclage.
en fait, dans l'ensemble (avec les ajouts les plus récents à JDK wrt JMX), je dirais que JMX Remote Lifecycle Listener de Tomcat est maintenant redondant sauf si vous voulez vous lier à une interface réseau vraiment étrange.
parce que jmx est encapsulé dans rmi qui est très pare-feu et nat inamical. Évitez - le si vous le pouvez, il existe une autre forme d'encapsulation appelée jmxmp.
regardez, cela pourrait vous aider : http://blog.markfeeney.com/2010/10/jmx-through-ssh-tunnel.html http://jrds.fr/sourcetype/jmx/start#jmx_protocols
utilisant Oracle Java SE 1.8.0_121.
il est possible de régler jmxremote.port et jmxremote.rmi.port à la même valeur, c'est moins un port ouvert. Il est également possible de régler jmxremote.host=127.0.0.1, pour que ce port (ou ces deux ports, si vous les définissez différemment) ne se lie qu'à l'interface de loopback.
un autre port est encore attribué dynamiquement, et se liera à 0.0.0.0. Je n'ai pas pu empêcher ce port avec - XX+Disablattachmécanisme, et n'a pas non plus été en mesure de le faire se lier à autre chose que 0.0.0.0.
comme pour le numéro que Michael a ouvert, cela semble être un comportement attendu https://bugs.openjdk.java.net/browse/JDK-8035404