2009-11-10 7 views
1

Je reçois le message suivant lorsque j'essaie de déboguer une application Java à distance via eclipse. "Impossible de se connecter à la machine virtuelle distante. Connexion refusée." Quelle pourrait être l'erreur?Application Java de débogage à distance

Répondre

3

Vous devez appeler le processus à déboguer avec les options appropriées, par ex. (Remplacez-le par le port approprié si nécessaire) et il semble que la VM n'écoute pas sur le port configuré. Vous pouvez utiliser netstat /a pour confirmer si la machine virtuelle est à l'écoute sur ce port (ou telnet)

+0

Quand j'ai essayé netstat/un j'ai eu: TCP DEV-MACHINE2: 8787 localhost: 1261 ESTABLISHED Ceci est la seule entrée pour le numéro de port 8787 que je utilise. – devnull

1

avez-vous le port 8000, ou quel que soit le port que vous avez configuré pour les connexions à distance ouvertes sur votre pare-feu?

+0

En ce moment, je suis en train de tester sur ma machine. Donc ce ne sera pas un problème non? – devnull

+0

non, il ne devrait pas être un problème si c'est sur la même machine ... –

1

L'application distante doit être démarrée en premier. Avez-vous ajouté les arguments à l'application distante cible afin qu'elle accepte une connexion de débogage?

+0

oui, j'ai commencé l'application à distance. – devnull

+0

Parfois, le port n'a pas été libéré depuis la dernière fois qu'il a été exécuté. Sous Windows, faites un 'netstat -a' et cherchez le port utilisé par l'application distante pour écouter les connexions de débogage. S'il est toujours ouvert, vous ne pourrez pas ouvrir une session de débogage à distance. Fermez le port/socket ou, s'il y en a, changez le port utilisé. Espérons que le premier socket se libère finalement avant que vous verrouilliez le second. –

1

Assurez-vous que votre machine virtuelle Java a commencé avec ces options

-Xdebug -Xrunjdwp: transport = dt_socket, adresse = 8000, server = y, suspension = n

et que le port 8000 est libre

+0

Comment vérifier si le port est libre .. – devnull

+0

juste faire un netstat -an | Grep 8000 –

2

Pour le débogage client, je suis tombé sur la même question

URL -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=4081 

La modification du numéro de port a résolu le problème.

Questions connexes