Pourquoi java rmi garder la connexion à 127.0.1.1. Lors de l'ip 192.168.X.X?

J'ai un java rmi application je n'ai tout simplement:

Client:

Registry registry = LocateRegistry.getRegistry("localhost");
costApi = (CostApi) registry.lookup("server.CostApi");

Tout fonctionne bien quand je l'hôte du serveur en localhost. Quand je lance le même programme sur une autre machine dans le réseau local, à 192.168.x.x et changement:

Client:

Registry registry = LocateRegistry.getRegistry("192.168.x.x");
costApi = (CostApi) registry.lookup("server.CostApi");

il ne fonctionne plus et il échoue avec une très étrange erreur:

java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is: 
    java.net.ConnectException: Connection refused
    at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
    at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
    at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:129)
    at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:194)
    at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:148)
    at com.sun.proxy.$Proxy0.dataCost(Unknown Source)
    at billing.data.DataBiller.performBilling(DataBiller.java:57)
    at billing.data.DataBiller.consumeMessage(DataBiller.java:46)
    at general.templates.RabbitWorker.run(RabbitWorker.java:124)
    at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.ConnectException: Connection refused
    at java.net.PlainSocketImpl.socketConnect(Native Method)

Je ne suis même pas essayer de se connecter à 127.0.1.1 mais à 192.168.x.x, comment puis-je résoudre ce problème? Je préfère utiliser du code java uniquement et de ne pas modifier ma machine avec des fichiers de configuration. J'utilise linux

Votre /etc/hosts fichier est erroné.
Avez-vous essayez de mettre à jour votre hosts fichier avec un nom d'hôte spécifique, et ensuite passé que le nom d'hôte à getRegistry au lieu de l'adresse IP?
Oui j'ai essayé et cela n'a pas fonctionné. Maintenant 127.0.1.1 est mon nom d'utilisateur de l'ordinateur et j'ai aussi changé de 192.168.x.x
Le chemin du RMI œuvres de la première connexion à la base de registre et lui demander l'adresse de l'objet qui vous intéresse, puis connectez-vous à l'adresse du registre vous a donné pour parler de l'objet cible. Vous êtes connecté à la de registre sur 192.168.x.x mais le registre vous a donné 127.0.1.1 que l'adresse de l'objet cible.

OriginalL'auteur user264230 | 2014-05-05

  1. 8

    Ceci est généralement dû à une mauvaise configuration. Vérifiez votre /etc/hosts dossier pour s'assurer que:

    • localhost cartes à l'adresse 127.0.0.1
    • votre vrai nom d'hôte correspond à votre véritable adresse de l'hôte

    Certaines distributions de Linux sont connus pour avoir cet arrière vers l'avant.

    Si le problème persiste, essayez de définir java.rmi.server.hostname sur le serveur à l'adresse IP, le client doit utiliser lors de l'exécution à distance des appels de méthode. Il doit être défini avant d'exporter les objets à distance, y compris le Registre.

    Le problème est causé par l'adresse IP intégré dans le talon, qui vient finalement de quelque chose comme InetAddress.getLocalAddress(), qui est faillible comme ci-dessus. Elle est remplacée par java.rmi.server.hostname.

    C'est l'élément A. 1 de la FMI FAQ, mais notez que l'article est mistitled. Il ne se produit pas au cours de lookup(), il se produit lorsque vous appelez une méthode à distance sur le talon.

    Pouvez-vous expliquer cela: votre vrai nom d'hôte correspond à votre véritable adresse de l'hôte. J'ai deux entités en vertu de l'ipv4 configuarain dans /etc/hosts 127.0.0.1 localhost 127.0.1.1 mon nom d'utilisateur c'Est bon? "Certaines distributions de Linux sont connus pour avoir cet arrière vers l'avant." est-ce que j'ai? J'ai essayé de changer 127.0.1.1 à mon 192.168.x.x adresse et il ne fonctionne pas:/
    Si c'est votre adresse IP correcte, il doit avoir travaillé.
    /etc/hosts n'est certainement pas carte mon hostname de mon adresse IP. Comme c'est un portable, il passe les adresses IP sur des bases régulières, et /etc/hosts est censé être un statique fichier de configuration. Si RMI dépend que cela fonctionne correctement, je considérerais que ce soit le problème.
    Il dépend d'elle de ne pas avoir le bug mentionné dans la FAQ. localhost et 127.0.0.1 devrait en effet être mappé statiquement les uns aux autres, et rien d'autre, et le problème se pose lorsqu'elles ne le sont pas.

    OriginalL'auteur user207421

  2. 2

    Je viens de tomber sur le même problème. Je suis en train de faire quelque chose de très similaire à ce que vous faites. Ce que j'ai remarqué était que la première fois que j'ai couru le programme client, et il a échoué ( par la conception du pare-feu test ) - qu'il a échoué avec un message d'erreur indiquant l'adresse ip de l'hôte que j'ai spécifié ( 192.168.x.x adresse ), mais tous les échecs ultérieurs montrent qu'il n'arrive pas à établir une connexion à l'adresse 127.0.0.1. Actuellement, je suis soupçonner une sorte de mise en cache sur le client a la JVM marqué que l'adresse ip que jamais accessible à nouveau et c'est en refusant jamais essayer de vous connecter à nouveau?

    Mise à JOUR: Dans mon cas, la JVM sur le RMI côté Serveur n'a pas été en mesure de définir correctement la java.rmi.serveur.nom d'hôte de la propriété à la JVM de démarrage. Cette propriété était laissé null. Lorsque des clients se connectent à un Registre RMI et de demander un tampon à un objet nommé, ils reçoivent un tampon contenant l'adresse ip de la machine distante où l'objet réel peut être trouvé. Le RMI serveur copie le contenu de la java.rmi.serveur.nom d'hôte de la propriété dans les bouchons, il revient à les clients, de sorte que si le java.rmi.serveur.nom d'hôte de la propriété est "" et les copies qui à chaque talon, il crée, chaque talon contient une référence vers un serveur distant avec une adresse IP de "". Par défaut, le client jvm réagit à cela en essayant de se connecter au serveur de l'objet sur le localhost, 127.0.0.1. Pour contourner le problème, essayez cette ligne de code avant de l'exporter des objets à distance sur le serveur:

    System.setProperty( "java.rmi.server.hostname", "192.168.RMIServer.IP" ) ;

    Cette propriété sera automatiquement copié dans tous les talons de exportés sur ce serveur, et les clients qui reçoivent ce stub doit alors être en mesure d'atteindre le serveur distant ( en supposant que tous les pare-feu sont configurés correctement ).

    La propriété n'a pas à être défini, et si elle n'est pas définie, RMI obtient le nom d'hôte via la classe InetAddress comme expliqué dans ma réponse. Il ne crée pas une référence à "" et la JVM ne pas " réagir à ce, de la manière décrite, parce que ça n'arrive jamais.
    Pardonnez-moi, je erronée que fait - si la JVM est pas en mesure de déterminer l'adresse ip de l'hôte à l'aide des méthodes de la classe InetAddress, la java.rmi.serveur.nom d'hôte de la propriété n'est jamais créé plutôt que d'être créé "". Cependant, je suis toujours curieux - Dans ce cas, le serveur de créer le tampon sans référence à l'adresse ip ou le nom d'hôte du serveur RMI, ou n'a le tampon obtenez créé et rempli automatiquement avec "localhost" ou 127.0.0.1 comme l'emplacement de la télécommande rmi serveur?

    OriginalL'auteur user3623873