remote access on EAP 5.1.2 not working

[spyhunter99]

I have a simple test jms client that uses a jnp lookup to access a hornetq broker running within jboss eap 5.1.2.

The test application works perfectly when running on the same machine as jboss.

When running the same test app from a remote machine, i've been getting the following:

javax.naming.CommunicationException [Root exception is java.rmi.NoSuchObjectException: no such object in table]

        at org.jnp.interfaces.NamingContext.list(NamingContext.java:967)

        at org.jnp.interfaces.NamingContext.list(NamingContext.java:922)

        at javax.naming.InitialContext.list(Unknown Source)

It looks like netty is listening on the correct ports

Jboss starts with the options for -b 0.0.0.0 to bind to all addresses.

Any ideas?

[ataylor]

its hard to say with such little information, however it doesnt look like a HornetQ issue.

[spyhunter99]

What information do you need?

One more potential cause, I'm using the shifted port configuration for Jboss, so everything that normall is at 8080 is at 8180. Netty for Hornet is normallly 5445, but in my case its on 5545. JNP is normally 1099, but mine is 1199 and so forth.

java.naming.factory.initial = org.jnp.interfaces.NamingContextFactory

java.naming.provider.url = jnp://myhostname:1199

Destination = topic/myTopic

DestinationType = topic

java.naming.factory.url.pkgs = org.jboss.naming:org.jnp.interfaces

ConnectionFactoryLookup = /ConnectionFactory

Again this works fine from localhost, but not remotely.

Netstat -an shows something listening on 5545 and 1199 for 0.0.0.0

[jbertram]

It looks to me like your client is failing during the JNDI lookup so it isn't even getting to Netty at this point.

Can you paste the code for your client as well as the full stack-trace of the exception?

Also, if you are really using EAP then I recommend you take advantage of the professional support offered via the Red Hat Customer Portal rather than using a community forum where there is no SLA.

[spyhunter99]

The rest of the stack trace is references to my code.

        Context ic = null;

        ConnectionFactory cf;

        Connection con = null;

            p.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");

            p.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");

            p.put(Context.PROVIDER_URL, "jnp://localhost:1199");

            p.put("ConnectionFactoryLookup", "/ConnectionFactory");

            ic = new InitialContext(p);

            String destination= "topic/myTopic"

            cf = (ConnectionFactory) ic.lookup("/ConnectionFactory");          //this is where it fails

            MessageConsumer sub = null;

            con = cf.createConnection();

            Session s = con.createSession(false, Session.AUTO_ACKNOWLEDGE);

            Topic topic = (Topic) ic.lookup(destination);

            sub = s.createConsumer(topic);

            sub.setMessageListener(this);

            con.start();

[spyhunter99]

Interestingly, I just ran the same code on another machine. Different stack trace this time.

Sep 13, 2012 12:20:18 PM org.hornetq.core.logging.impl.JULLogDelegate warn

WARNING: Tried 1 times to connect. Now giving up on reconnecting it.

javax.jms.JMSException: Failed to create session factory

        at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:615)

        at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:121)

        at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:116)

        at my code.... con = cf.createConnection();

Caused by: HornetQException[errorCode=2 message=Cannot connect to server(s). Tried with all available servers.]

        at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:619)

        at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:611)

        ... 5 more

[jbertram]

The rest of the stack trace is references to my code.

Yes, that is what I figured, and that's exactly why I wanted to see it.  I wanted to see which line of your code is triggering the exception and then see the actual code involved.  The presence of javax.naming.InitialContext.list in your stack-trace seems odd to me as I would not expect that method call during a normal lookup.

The code looks fine as far as I can tell.  I use code essentially just like this all the time.  I suspect your issue is caused by something in your environment.  Are you sure you're using the proper client libraries?

[jbertram]

In my mind that confirms that your previous problem was caused by something environmental.

In this case the JNDI lookup has succeeded, but the Netty connection cannot be established to the server.  Again, I suspect something environmental. 

[spyhunter99]

Well I've confirmed that the firewall is off on both machines and that they can ping each other.

Client jar list as follows. All of these are from the client lib folder of Jboss following the tutorial at http://www.mastertheboss.com/jboss-jms/jboss-hornetq-simple-tutorial

hornetq-bootstrap.jar

hornetq-core-client.jar

hornetq-core.jar

hornetq-jboss-as-integration.jar

hornetq-jms.jar

hornetq-logging.jar

jboss-jms-api_1.1_spec.jar

jboss-logging.jar

jboss-messaging-client.jar

jnp-client.jar

netty.jar

Am I perhaps missing something?

[spyhunter99]

I have a wireshark capture of this happening.

It looks like the client when from the jnp lookup on port 1199 and then connected to port 1198

Following the tcp stream, I can see a number of serialized rmi objects. I did a quick search for the exported port number of 5545 and found this:

port ..5545

host.0.0.0.0

So I change the startup parameters for jboss to switch from -b 0.0.0.0 to a external accessible address 192.168.x.x

Presto, it works.

Jboss can't be bound to 0.0.0.0 and have JMS work when using jnp lookups.

[jbertram]

The fact that you were using 0.0.0.0 should have jogged my memory.  See https://issues.jboss.org/browse/HORNETQ-952.