JNDI & JBoss 127.0.0.1:1098 problem

[Chris White]

Hi

Im using JBoss 3.2.2 on a redhat linux 7.2 machine. I have JMS running
between a client applet, a Java bean and an application (app running
on same machine as JBoss server.)

When i try to do a JNDI lookup on my JMS Topic Connection Factory i
get the following exception:

java.security.AccessControlException: access denied
(java.net.SocketPermission 127.0.0.1:1098 connect,resolve)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:270)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
at java.lang.SecurityManager.checkConnect(SecurityManager.java:1044)
at sun.rmi.transport.proxy.RMIMasterSocketFactory$AsyncConnector.<init>(RMIMasterSocketFactory.java:350)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:147)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:562)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:101)
at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:528)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
......
......

I am 100% sure that i have set java.naming.provider.url=x.x.x.x:1099
(where x is server machine ip, and have confirmed with a debug print
statement before the lookup. Why (oh why..) in the exception trace is
it trying to connect to port 1098 ?? I know this is the RMI port, but
why is it not looking at the same IP address provided in
java.naming.provider.url ??.

Anyway a simple solution to this is to put
-Djava.rmi.server.hostname=x.x.x.x in the run.sh script (jboss/bin/
directory). However, with this in place i can get the applet/app
comunication via bean to work successfully off a single machine, but
once i load the browser in another machine, the JMS reply messages are
never seen by the remote applet. Debug statements in the applets shows
that the message was successfully posted to the Topic (as seen in the
both local and remote applets), but the remote applet never sees the
reply message post (the local applet does see the reply).

The annoying thing is that other people have taken the same code and
dont have the problems i have (they dont need to set
-Djava.rmi.server.hostname=x.x.x.x in run.sh), and they dont get the
127.0.0.1:1098 exception.

Any help would be appreciated.

Thanks

Chris

[Chris White]

Ok, actually its RH 7.3.

Ive got around the 127.0.0.1:1098 problem with the following (i no
longer need -Djava.rmi.server.hostname=x.x.x.x in JBoss run.sh
script):

Ensure the Redhat machine has a configured hostname, and the the
/etc/hosts file looks similar to below (obviously you can have more
entries):

127.0.0.1 localhost.localdomain localhost
10.129.1.2 mymachinename

An entry such as:

127.0.0.1 mymachinename localhost.localdomain localhost

Will not suffice.

I still have the problem that the JMS messages are not making their
way back to the windows machine. I suspect this has further to do with
the /etc/hosts file (possibly on the win2k machine as well, if the
linux machine is not listed in your local network DNS).

[Chris White]

Ok, ive removed Linux from my machine and installed NT4, but still no
joy on the return messages. Im starting to think this could be a
hardware related problem. I have other Linux and Win 2K machines
running fine.

[Chris White]

Ok ive realised how bad a job JMS does with regard to message delivery
and expired message dropping. My applet machine was receiving the
reply message (as seen using ethereal), however before the message was
being passed to the Applet 'layer' if you will, the JMS manager had
its evil hand in deciding that the message had expired and therefore
dropped it. Surely setting the message timeout to be larger would
solve this and in any case i can see via the network traffic that the
response was deliverd in well under the timeout period.

The problem was to do with clock synchronisation. The server machine's
clock was 5 or 6 minutes slower than the client (applet end).
Therefore looking at the timestamps and the expiration time, the
applet JMS dropped the message. as it expired some 3/4 minutes ago.

Surely a better implementation of JMS would examine the server send
time and client receive time and use some sort of sync'ing to
determine that yes, the clocks are out by 6 minutes and account
accordingly.