2010-03-26 10 views
2

J'ai créé une fabrique de connexions JMS sur un serveur glassfish distant et souhaite utiliser ce serveur à partir d'une application cliente java sur ma machine locale. J'ai la configuration suivante pour obtenir le contexte et l'usine connexion:Connexion JMS distante utilisant toujours localhost

Properties env = new Properties(); 
env.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory"); 
env.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming"); 
env.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl"); 
env.setProperty("org.omg.CORBA.ORBInitialHost", JMS_SERVER_NAME); 
env.setProperty("org.omg.CORBA.ORBInitialPort", "3700"); 

initialContext = new InitialContext(env); 
TopicConnectionFactory topicConnectionFactory = (TopicConnectionFactory) initialContext.lookup("jms/MyConnectionFactory"); 
topicConnection = topicConnectionFactory.createTopicConnection(); 

topicConnection.start(); 

Cela semble fonctionner et quand je supprime le ConnectionFactory du serveur GlassFish je reçois une exception indiquant ce qui est ne peut pas trouver jms/MyConnectionFactory comme prévu .

Cependant, lorsque j'utilise par la suite mon topicConnection pour obtenir un sujet, il essaie de se connecter à localhost: 7676 (cela échoue car je ne suis pas en train d'exécuter glassfish localement).

Si je crée dynamiquement un sujet:

TopicSession pubSession = topicConnection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE); 
Topic topic = pubSession.createTopic(topicName); 
TopicPublisher publisher = pubSession.createPublisher(topic); 
Message mapMessage = pubSession.createTextMessage(message); 
publisher.publish(mapMessage); 

et le serveur GlassFish ne fonctionne pas je reçois localement la même connexion a refusé cependant, si je commence mon serveur GlassFish local, les sujets sont créés localement et je peux voir eux dans la console d'administration glassfish.

Si vous demandez que je n'ai pas jms/MyConnectionFactory sur mon instance locale de glassfish, il n'est disponible que sur le serveur distant.

Je ne vois pas ce que je fais de mal ici et pourquoi il essaie d'utiliser localhost du tout.

Des idées?

Cheers,

James

Répondre

2

Il faut distinguer entre l'obtention de l'objet ConnectionFactory et les connexions qu'il ouvre. L'objet ConnectionFactory est géré par JNDI (supporté par CORBA dans ce cas). Une fois l'objet ConnectionFactory obtenu, il utilise son paramètre imqAddressList pour ouvrir la connexion à un ou plusieurs courtiers JMS. Par défaut, il est configuré pour localhost: 7676 et vous devez configurer une valeur correcte si vous voulez ouvrir des connexions aux courtiers distants.

Vous devez vérifier comment ce paramètre est configuré pour cette TopicConnectionFactory liée à jms/MyConnectionFactory. Voir Administering JMS Connection Factories and Destinations pour plus de détails sur la configuration des fabriques de connexions dans Glassfish.

+0

Merci pour l'aide. J'ai ajouté AddressList sur mon ConnectionPoolFactory maintenant j'obtiens l'erreur suivante: org.omg.CORBA.COMM_FAILURE: vmcid: Code mineur de SUN: 201 accompli: Non Des idées? – James

+0

Plus d'infos, je peux maintenant voir les sujets dynamiques sur les pages d'administration du serveur glassfish distant mais seulement si je cours une instance locale de glassfish. Sans la version locale en cours d'exécution, j'obtiens l'exception de mon précédent commentaire. – James

+0

J'ai eu ce problème avec un serveur 3.1.2.2 Glassfish et je suis prêt à crier. J'ai construit un client distant avec le gf-client.jar et le appclient.jar que j'ai construit suite à la suggestion d'Oracle à http://docs.oracle.com/cd/E26576_01/doc.312/e24930/java-clients.htm# gkuqa. J'ai suivi les suggestions d'Arnoud et vos suggestions. Il semble se connecter à l'hôte/port correct mais j'obtiens une étrange NumberFormatException: AVERTISSEMENT: [C4003]: Une erreur s'est produite lors de la création de la connexion [10.20.10.207:3700]. - cause: java.lang.NumberFormatException: Pour la chaîne d'entrée :. Des idées pourquoi? – kpenrose

4

J'ai rencontré un problème similaire en essayant d'effectuer une recherche JNDI à distance pour les EJB. La question est que dans mon/etc/hosts fichier le nom de la machine a été mise en correspondance avec quelque chose comme hôte local:

127.0.0.1 glassfish localhost.localdomain localhost 

Pour rechercher une ressource, deux connexions. Le premier consiste à trouver l'emplacement du serveur que vous devriez rechercher. La seconde utilise cette adresse IP pour effectuer la recherche. Dans votre cas, la première connexion renvoie localhost (127.0.0.1). Votre application essaie de se connecter à localhost pour faire la recherche et ne peut pas parce qu'il n'y a pas de glassfish en cours d'exécution localement. Pour résoudre ce problème Assurez-vous que votre fichier hôte ressemble à quelque chose comme:

127.0.0.1 localhost 
192.168.1.10 glassfish //(or what ever your server name is). 

Vous pouvez en savoir plus here.

2

J'ai eu un problème similaire avec l'obtention de ressources JMS à partir d'une machine différente, puis la machine fonctionnant sous GlassFish (v3.0.1 dans mon cas).

Pour le faire fonctionner, je l'ai fait ce qui suit:

  • l'hôte fait en sorte que JMS a été défini sur le nom d'hôte de la machine serveur (par défaut est localhost). [Configuration-> Java Message Service-> Hôtes JMS]
  • Comme Matej l'a suggéré, assurez-vous que la propriété imqAddressList utilise le même nom d'hôte. Plutôt que de configurer les propriétés dans un objet Properties et de fournir cet objet à InitialContext, je les ai définies en tant que propriétés de la machine virtuelle Java (JVM). Ces propriétés peuvent être fournis lors du démarrage de votre application (java -Dorg.omg.CORBA.ORBInitialHost=myServerHost ...) ou par le code (System.setProperty("org.omg.CORBA.ORBInitialHost","myServerHost");)

La dernière mesure pour moi était nécessaire parce que pendant le chargement des ressources JMS, une classe interne (com.sun.enterprise .naming.factory.AdministeredObjectFactory et peut-être d'autres) ont créé un nouveau InitialContext sans prendre en compte les propriétés que j'ai fournies. Ce InitialContext nouvellement créé faisait toujours référence à localhost plutôt qu'à myServerHost.

La définition des propriétés en tant que propriétés JVM fonctionne car InitialContext prend en compte par défaut l'ensemble de propriétés JVM pertinent. Tout composant (interne) qui crée un nouveau InitialContext utilisera automatiquement les paramètres corrects.