Remote JMS connection still using localhost

Question

I have a created a JMS Connection Factory on a remote glassfish server and want to use that server from a java client app on my local machine. I have the following configuration to get the context and connection factory:

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();

This seems to work and when I delete the ConnectionFactory from the glassfish server I get a exception indicating that is can't find jms/MyConnectionFactory as expected.

However when I subsequently use my topicConnection to get a topic it tries to connect to localhost:7676 (this fails as I am not running glassfish locally).

If I dynamically create a topic:

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);

and the glassfish server is not running locally I get the same connection refused however, if I start my local glassfish server the topics are created locally and I can see them in the glassfish admin console.

In case you ask I do not have jms/MyConnectionFactory on my local glassfish instance, it is only available on the remote server.

I can't see what I am doing wrong here and why it is trying to use localhost at all.

Any ideas?

Cheers,

James

Answer 1

I have run across a similar problem while trying to do a remote JNDI lookup for EJBs. The issue was that in my /etc/hosts file the machine name was mapped to local host something like:

127.0.0.1 glassfish localhost.localdomain localhost

To look up a resource, two connections are made. The first is to find the location of the server you should look for. The second uses this IP to do the lookup. In your case the first connect is returning localhost (127.0.0.1). Your application tries to connect to localhost to do the lookup and cannot because there is no glassfish running locally. To fix this make sure your host file looks something like:

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

You can find out more here .

Answer 2

You have to distinguish between obtaining the ConnectionFactory object and the connections that it opens. Obtaining ConnectionFactory object is handled by JNDI (backed by CORBA in this case). Once ConnectionFactory object is obtained, it uses its imqAddressList parameter to open the connection to a JMS broker(s). By default, it is configured to localhost:7676 and you have to configure a proper value if you want to open connections to remote brokers.

You have to check how is this parameter configured for that TopicConnectionFactory bound to jms/MyConnectionFactory. See Administering JMS Connection Factories and Destinations for more details about how to configure the connection factories within Glassfish.

Answer 3

I had a similar issue with obtaining JMS resources from a different machine then the machine running GlassFish (v3.0.1 in my case).

In order to get it to work I did the following:

• Ensured that the JMS host was set to the hostname of the server machine (default is localhost). [Configuration->Java Message Service->JMS Hosts]
• As Matej suggested, make sure the imqAddressList property uses the same hostname. [Resources->Connectors->Connector Connection Pool->yourJmsConnectionFactory]
• Rather then configuring the properties in a Properties object and supply that object to the InitialContext, I set them as properties of the JVM. Such properties can be supplied when starting your application ( java -Dorg.omg.CORBA.ORBInitialHost=myServerHost ...) or through code ( System.setProperty("org.omg.CORBA.ORBInitialHost","myServerHost"); )

The last measure for me was needed because while loading the JMS resources, some internal class (com.sun.enterprise.naming.factory.AdministeredObjectFactory and maybe others) created a new InitialContext without taking the properties I supplied into account. That newly created InitialContext was still referring to localhost rather then myServerHost.

Setting the properties as JVM properties works because InitialContext by default takes into account the relevant JVM properties set. Any (internal) component that creates a new InitialContext, will automatically use the correct settings.