Java jconsole jmx échec de la connexion

J'essaie de connecter jconsole à une jvm invoquée par:

java \
-Djava.util.logging.config.file=./logging.properties \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.port=12700 \
-cp . Sleep

Je puis essayez de démarrer avec jconsole:

jconsole -J-Djava.util.logging.config.file=./logging.properties

Le loggin.les propriétés de fichier comprend:

sun.rmi.level=FINEST

Après l'ouverture d'une socket au port 12700, rmi apparaît alors à tenter d'établir une connexion sur un autre port :

FINER: [javax.management.remote.rmi.RMIConnector: jmxServiceURL=service:jmx:rmi:///jndi/rmi://10.40.243.12:12700/jmxrmi] connecting...
Jan 5, 2012 2:30:42 PM RMIConnector connect
FINER: [javax.management.remote.rmi.RMIConnector: jmxServiceURL=service:jmx:rmi:///jndi/rmi://10.40.243.12:12700/jmxrmi] finding stub...
Jan 5, 2012 2:30:43 PM sun.rmi.transport.tcp.TCPEndpoint <clinit>
FINE: JConsole.addHost: localHostKnown = true, localHost = 10.206.6.59
Jan 5, 2012 2:30:43 PM sun.rmi.server.UnicastRef newCall
FINE: JConsole.addHost: get connection
Jan 5, 2012 2:30:43 PM sun.rmi.transport.tcp.TCPTransport <init>
FINE: JConsole.addHost: Version = 2, ep = [10.206.6.59:0]
Jan 5, 2012 2:30:43 PM sun.rmi.transport.tcp.TCPEndpoint getLocalEndpoint
FINE: JConsole.addHost: created local endpoint for socket factory null on port 0
Jan 5, 2012 2:30:43 PM sun.rmi.transport.tcp.TCPChannel createConnection
FINE: JConsole.addHost: create connection
Jan 5, 2012 2:30:43 PM sun.rmi.transport.tcp.TCPEndpoint newSocket
FINER: JConsole.addHost: opening socket to [10.40.243.12:12700]
Jan 5, 2012 2:30:43 PM sun.rmi.transport.proxy.RMIMasterSocketFactory createSocket
FINE: JConsole.addHost: host: 10.40.243.12, port: 12700
Jan 5, 2012 2:30:43 PM sun.rmi.transport.tcp.TCPChannel createConnection
FINER: JConsole.addHost: server suggested 10.206.6.59:12306
Jan 5, 2012 2:30:43 PM sun.rmi.transport.tcp.TCPChannel createConnection
FINER: JConsole.addHost: using 10.206.6.59:0
Jan 5, 2012 2:30:43 PM sun.rmi.server.UnicastRef newCall
FINER: JConsole.addHost: create call context
Jan 5, 2012 2:30:43 PM sun.rmi.server.UnicastRef logClientCall
FINER: JConsole.addHost: outbound call: [endpoint:[10.40.243.12:12700](remote),objID:[0:0:0, 0]] : sun.rmi.registry.RegistryImpl_Stub[0:0:0, 0]: java.rmi.Remote lookup(java.lang.String)
Jan 5, 2012 2:30:43 PM sun.rmi.transport.StreamRemoteCall <init>
FINER: JConsole.addHost: write remote call header...
Jan 5, 2012 2:30:43 PM sun.rmi.transport.StreamRemoteCall getOutputStream
FINER: JConsole.addHost: getting output stream
Jan 5, 2012 2:30:43 PM sun.rmi.server.UnicastRef invoke
FINER: JConsole.addHost: execute call
Jan 5, 2012 2:30:43 PM sun.rmi.transport.StreamRemoteCall getInputStream
FINER: JConsole.addHost: getting input stream
Jan 5, 2012 2:30:43 PM sun.rmi.server.LoaderHandler loadClass
FINE: JConsole.addHost: name = "javax.management.remote.rmi.RMIServerImpl_Stub", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@a39137
Jan 5, 2012 2:30:43 PM sun.rmi.server.LoaderHandler loadClass
FINER: JConsole.addHost: class "javax.management.remote.rmi.RMIServerImpl_Stub" found via defaultLoader, defined by null
Jan 5, 2012 2:30:43 PM sun.rmi.server.LoaderHandler loadClass
FINE: JConsole.addHost: name = "java.rmi.server.RemoteStub", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@a39137
Jan 5, 2012 2:30:43 PM sun.rmi.server.LoaderHandler loadClass
FINER: JConsole.addHost: class "java.rmi.server.RemoteStub" found via defaultLoader, defined by null
Jan 5, 2012 2:30:43 PM sun.rmi.server.LoaderHandler loadClass
FINE: JConsole.addHost: name = "java.rmi.server.RemoteObject", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@a39137
Jan 5, 2012 2:30:43 PM sun.rmi.server.LoaderHandler loadClass
FINER: JConsole.addHost: class "java.rmi.server.RemoteObject" found via defaultLoader, defined by null
Jan 5, 2012 2:30:43 PM sun.rmi.server.UnicastRef done
FINE: JConsole.addHost: free connection (reuse = true)
Jan 5, 2012 2:30:43 PM sun.rmi.transport.tcp.TCPChannel free
FINE: JConsole.addHost: reuse connection
Jan 5, 2012 2:30:43 PM sun.rmi.transport.tcp.TCPChannel free
FINE: JConsole.addHost: create reaper
Jan 5, 2012 2:30:43 PM sun.rmi.server.UnicastRef newCall
FINE: JConsole.addHost: get connection
Jan 5, 2012 2:30:43 PM sun.rmi.transport.tcp.TCPChannel createConnection
FINE: JConsole.addHost: create connection
Jan 5, 2012 2:30:43 PM sun.rmi.transport.tcp.TCPEndpoint newSocket
FINER: JConsole.addHost: opening socket to [tdiap12:41096]
Jan 5, 2012 2:30:43 PM sun.rmi.transport.proxy.RMIMasterSocketFactory createSocket
FINE: JConsole.addHost: host: tdiap12, port: 41096

La première tentative de connexion réussit, car sur le serveur distant, je peux voir la connexion ÉTABLIE.

wse2tst@tdiap12:~> netstat -a | grep 12700
tcp        0      0 *:12700                     *:*                         LISTEN      
tcp        0      0 tdiap12.vgcar.net:12700     per-00c0016253a2.vgca:12252 ESTABLISHED

La trace de paquet indique une connexion réussie.

La deuxième connexion au port 41096 fois, et la jconsole rapports de mise en œuvre d'un "échec de la Connexion" et met fin à la première connexion. Pourquoi une deuxième tentative de connexion? Est-il possible de spécifier le port pour ce deuxième lien? Le serveur cible est étroitement contrôlée, et d'autres ports sont bloqués par des règles de pare-feu. Sur de multiples tentatives de connexion, le deuxième port va changer pour différentes valeurs aléatoires.

Merci pour toute aide,
Steve

êtes-vous sûr qu'aucun pare-feu sur votre ordinateur de blocage 12700? Je soupçonne en raison de certaines de blocage, jmx essayer autre port. Essayez de désactiver votre pare-feu.
Lorsque j'essaie de me connecter à partir de mon local de la machine, la machine distante est le suivant:

wse2tst@tdiap12:~> netstat -a | grep 12700 tcp        0      0 *:12700                     *:*                         LISTEN       tcp        0      0 tdiap12.vgcar.net:12700     per-00c0016253a2.vgca:12252 ESTABLISHED

je suis en supposant que la connexion est en cours et n'est pas bloqué par une règle de pare-feu. Le paquet de trace indique également que la connexion est réussie.
Je suppose que vous devez ajouter-Dcom.soleil.de la gestion.jmxremote tout en apportant de la jvm que vous avez spécifié sur le dessus de cette question, ne faudrait-il pas?
Je n'ai pas vu que dans la documentation. Que pourrait-elle faire? Les deux premiers -Dcom.soleil.de la gestion.jmxremote des valeurs de cryptage et de sécurité. La troisième définit le port d'écoute pour la réception des connexions JMX. Je ne pense pas que configuration Dcom.soleil.de la gestion.jmxremote par lui-même pourrait avoir une incidence.
Essayez-la. Il laisse votre JVM look pour les connexions à distance.

OriginalL'auteur Steven | 2012-01-04

jconsole jmx

7

L'out-of-the-box JMX mise en œuvre utilise deux ports - un pour la base de registre (celui que vous avez spécifié) et un pour la connexion réelle qui est choisi au hasard (!). C'est un défaut de conception depuis le tirage au sort de la deuxième port le rend très difficile à configurer un pare-feu.

Il y a des façons de contourner cela toutefois - soit vous pouvez le faire vous-même manuellement, ou si vous utilisez Tomcat vous laisser en chargera pour vous.

S'avère un autre développeur a déjà codé un agent personnalisé pour contourner le problème du pare-feu bloque la deuxième port aléatoire. J'étais déterminé à aller au fond du problème au lieu d'avoir à installer le custom agent de partout, je devais surveiller. (J'ai pour surveiller des tonnes de serveurs d'applications.) J'ai eu extrêmement frustré parce que je n'ai jamais trouvé la documentation permettant d'identifier le deuxième port exigence, mais vous avez au moins confirmé mes observations, et c'est assez bon pour moi. Merci pour la réponse.

OriginalL'auteur Jens Borgland
8

de nouveaux et de meilleure solution que d'utiliser un codées manuellement l'agent, est d'utiliser le nouveau paramètre qui semble être introduit dans Java 7:

-Dcom.sun.management.jmxremote.rmi.port=7091

Donc en combinaison - même port peut être utilisé:

-Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.rmi.port=7091

Solution trouvée ici:
http://hirt.se/blog/?p=289

OriginalL'auteur Shivan
2

assurez-vous d'exécuter votre application en utilisant la commande ci-dessous,
```
java -Dcom.sun.management.jmxremote.port=9595 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -jar <your jar file name>
```
puis ouvrez jconsole avec des privilèges administrateur; vous pourriez être en mesure de se connecter sans aucun problème.

si vous souhaitez exécuter plusieurs fichiers jar, assurez-vous d'utiliser des ports différents, sinon il sera donner d'erreur disant que c'est déjà se lier par la JVM

Merci de ne pas poster en double réponses à de multiples questions.

OriginalL'auteur Isuru Dewasurendra
0

Vous pouvez définir le deuxième port avec le paramètre -"Dcom.soleil.de la gestion.jmxremote.rmi.port" où le numéro de port peut être la même que celle de la première . Même après le réglage de ce qu'il va promt précaire connexion ... s'il vous plaît permettre à l'insécurité de connexion alors seulement il va vous permettre d'aller plus loin sinon jusqu'alors dans le journal, vous trouverez d'erreur impossible de se connecter: java.lang.SecurityException: Attend à un soleil.rmi.serveur.UnicastRef2 de référence à distance dans le talon!

Grâce

OriginalL'auteur Rajesh Katadi

Vous devez vous connecter pour publier un commentaire.