A few problems running the examples on different machines

[timfox]

I thought I'd try and run the examples with server and client on different machines but ran into a few issues.

Whatever I tried the JMS examples always tried to lookup the name server on localhost, which clearly failed. I had to hack the example and hardcode a jndi server host to get it to work.

For the core examples, the server name, port etc, is also hardcoded, so I had to hack this too.

Any server hosts, ports etc should be in a local build.properties or jndi.properties so they can be changed by the user.

[ataylor]

there is a jndi.properties under docs/examples/jms/etc which gets picked up. Ive just tested it and it seems to work fine

[timfox]

I just did the following:

ant clean
ant distro
cd build/messaging-2.0.0.alpha1/docs/examples/jms/etc
vi jndi.properties
[changed ip address of server to 192.168.0.51 - my server]
cd ..
ant queueExample

and I get:

queueExample:
 [java] javax.naming.CommunicationException [Root exception is java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is:
 [java] java.net.ConnectException: Connection refused]
 [java] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:782)
 [java] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629)
 [java] at javax.naming.InitialContext.lookup(InitialContext.java:351)
 [java] at org.jboss.jms.example.QueueExample.main(QueueExample.java:47)
 [java] Caused by: java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is:
 [java] java.net.ConnectException: Connection refused
 [java] at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:574)
 [java] at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
 [java] at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
 [java] at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:94)
 [java] at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:179)
 [java] at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:132)
 [java] at $Proxy0.lookup(Unknown Source)
 [java] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:669)
 [java] ... 3 more
 [java] Caused by: java.net.ConnectException: Connection refused
 [java] at java.net.PlainSocketImpl.socketConnect(Native Method)
 [java] at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
 [java] at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
 [java] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
 [java] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
 [java] at java.net.Socket.connect(Socket.java:520)
 [java] at java.net.Socket.connect(Socket.java:470)
 [java] at java.net.Socket.<init>(Socket.java:367)
 [java] at java.net.Socket.<init>(Socket.java:180)
 [java] at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)
 [java] at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)
 [java] at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEnd

Any ideas what I am doing wrong.

The core client test SimpleClient works ok as long as I manually change the hardcoded server address in the Location object

[ataylor]

if i change it the same way i get

queueExample:
 [java] javax.naming.CommunicationException: Could not obtain connection to any of these urls: thetaylors:1099 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server thetaylors:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server thetaylors:1099 [Root exception is java.net.UnknownHostException: thetaylors: thetaylors]]]
 [java] at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1601)
 [java] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:636)
 [java] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629)
 [java] at javax.naming.InitialContext.lookup(InitialContext.java:351)
 [java] at org.jboss.jms.example.QueueExample.main(QueueExample.java:47)
 [java] Caused by: javax.naming.CommunicationException: Failed to connect to server thetaylors:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server thetaylors:1099 [Root exception is java.net.UnknownHostException: thetaylors: thetaylors]]
 [java] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:276)
 [java] at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1572)
 [java] ... 4 more
 [java] Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server thetaylors:1099 [Root exception is java.net.UnknownHostException: thetaylors: thetaylors]
 [java] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:250)
 [java] ... 5 more
 [java] Caused by: java.net.UnknownHostException: thetaylors: thetaylors
 [java] at java.net.InetAddress.getAllByName0(InetAddress.java:1128)
 [java] at java.net.InetAddress.getAllByName0(InetAddress.java:1098)
 [java] at java.net.InetAddress.getAllByName(InetAddress.java:1061)
 [java] at java.net.InetAddress.getByName(InetAddress.java:958)
 [java] at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:76)
 [java] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:246)
 [java] ... 5 more

so it looks like its picking it up for me

[timfox]

Yeah, I get the same as you if I put in a nonsense host name, so it does like it is picking up jndi.properties.

However if I put in the correct host name I get the original error I posted.

[ataylor]

do you still have localhost set in the jbm-configuration.xml file. This will need changing as well.

[timfox]

"ataylor" wrote:
do you still have localhost set in the jbm-configuration.xml.

No, it uses the correct hostname in jbm-configuration.xml and jbm-standalone-beans.xml

[ataylor]

ok, so it turns out that even tho the initial connection to jndi was happening the exported stub that was being returned still had an endpoint of localhost. This is because if the property java.rmi.server.hostname is not set it defaults to localhost, when the App Server starts up, setting this property is one of the first things it does.

Ive changed the jbm-standalone-beans.xml to inject the host property from the configuration object so that we only need to configure it in one place. The configuration property also sets the java.rmi.server.hostname property when the host is set.

[ataylor]

Of course if we wanted we could implement our own simple naming service using Mina. We only have to handle destinations and connection factories. This would remove the dependency!

[timfox]

"ataylor" wrote:
ok, so it turns out that even tho the initial connection to jndi was happening the exported stub that was being returned still had an endpoint of localhost. This is because if the property java.rmi.server.hostname is not set it defaults to localhost, when the App Server starts up, setting this property is one of the first things it does.

Ive changed the jbm-standalone-beans.xml to inject the host property from the configuration object so that we only need to configure it in one place. The configuration property also sets the java.rmi.server.hostname property when the host is set.

Nice catch. Sounds like a nasty one to track down.

[timfox]

"ataylor" wrote:
Of course if we wanted we could implement our own simple naming service using Mina. We only have to handle destinations and connection factories. This would remove the dependency!

Would we really need that?

JBM is fully functional without any need for JNDI - since connection factories and destinations can be instantiated directly on the client side.

The only reason we really need JNDI is for JMS spec which mentions that JMS objects should be available in JNDI.

[adridi]

"ataylor" wrote:
ok, so it turns out that even tho the initial connection to jndi was happening the exported stub that was being returned still had an endpoint of localhost. This is because if the property java.rmi.server.hostname is not set it defaults to localhost, when the App Server starts up, setting this property is one of the first things it does.

Ive changed the jbm-standalone-beans.xml to inject the host property from the configuration object so that we only need to configure it in one place. The configuration property also sets the java.rmi.server.hostname property when the host is set.

Hi Andy,

I installed JBM2 - beta release from trunk and was not able to run the examples, the following error was thrown:

javax.naming.CommunicationException [Root exception is java.rmi.ConnectException: Connection refused to host: 192.168.2.115; nested exception is:
java.net.ConnectException: Connection refused: connect

It looks like you fixed it in the alpha release by injecting the hostname into the naming service from the configuration object.

By checking "jbm-standalone-beans.xml", I noticed that your fix was rolled back.

Can you please provide some light on this?

Thanks,
Abdel

[clebert.suconic]

You have checked it out from SVN, right?


I also had some problems doing that on trunk. I guess it needs some quick tidy up on code in order to run it remotely.

[adridi]

Yes I checked out from SVN.
However this was already fixed by Andy but some how it was rolled back.

I was looking forward to test the cluster feature and play with it a little - do you have any documentation about it?

Thanks to all of the JBM2 team - you guys are doing great stuff.

[clebert.suconic]

"adridi" wrote:
Yes I checked out from SVN.
However this was already fixed by Andy but some how it was rolled back.

I would have to ask Andy (I think he would do it quickly).. I'm not sure. It's probably a very easy fix.... or maybe I will take a look over the weekend.

I was looking forward to test the cluster feature and play with it a little - do you have any documentation about it?

Actually.. that's where we are most currently working on.

The main difference between 1.4 and 2.0 will be the backup nodes for failover.

Thanks to all of the JBM2 team - you guys are doing great stuff.

Thanks... but Actually.. I say than you for trying it out. :-)