Hello. I have an interesting (to me) problem with the JNDI service on
JBoss. I am trying to use the JBoss naming in lieu of an RMI
registry.

Consider the following scenario:

- There are three machines in this system: hyena, cheetah, and
stallion.
- There are three components in this system: JBoss itself, a Service,
and a Client. The Service and the Client are stand-alone Java applications.
- The Service class extends UnicastRemoteObject and implements a
Remote interface. The Service binds itself to the namespace.
- The Client looks up the Service in the namespace and tries to invoke
a method on it.
- Both the Client and the Service use the same code for setting up
communication with the naming system:

private void init() throws Exception {
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"org.jnp.interfaces.NamingContextFactory");
String jndiHost = System.getProperty("jndiHost",
"jnp://localhost:1099");
env.put(Context.PROVIDER_URL, jndiHost);
env.put(Context.URL_PKG_PREFIXES,
"org.jboss.naming:org.jnp.interfaces");

theRealContext = new InitialContext(env);
}

Now consider the following table, which shows JBoss, the Service, and
the Client running on the three machines in this system. The table
shows how varying the deployment and the passed in 'jndiHost' property
effects the running of the Client. Note that in the first set of
tests, JBoss was not running at all. Subsequent tests have JBoss
co-located with the Service, or the Client, or neither.

jndiHost JBoss Service Client Success

localhost no hyena hyena yes
localhost:1099 no hyena hyena yes
rmi://localhost no hyena hyena yes
rmi://localhost:1099 no hyena hyena yes
http://localhost:1099 no hyena hyena yes
jnp://localhost:1099 no hyena hyena yes

localhost:1099 hyena hyena hyena no
http://localhost:1099 hyena hyena hyena yes
rmi://localhost:1099 hyena hyena hyena yes
jnp://localhost:1099 hyena hyena hyena no

hyena:1099 hyena hyena hyena no
http://hyena:1099 hyena hyena hyena yes
rmi://hyena:1099 hyena hyena hyena yes
jnp://hyena:1099 hyena hyena hyena no

10.10.10.85:1099 hyena hyena hyena no
http://10.10.10.85:1099 hyena hyena hyena yes
rmi://10.10.10.85:1099 hyena hyena hyena yes
jnp://10.10.10.85:1099 hyena hyena hyena no

127.0.0.1:1099 hyena hyena hyena no
http://127.0.0.1:1099 hyena hyena hyena yes
rmi://127.0.0.1:1099 hyena hyena hyena yes
jnp://127.0.0.1:1099 hyena hyena hyena no

cheetah:1099 cheetah hyena hyena yes
http://cheetah:1099 cheetah hyena hyena yes
rmi://cheetah:1099 cheetah hyena hyena yes
jnp://cheetah:1099 cheetah hyena hyena yes

cheetah:1099 cheetah cheetah hyena yes
http://cheetah:1099 cheetah cheetah hyena yes
rmi://cheetah:1099 cheetah cheetah hyena yes
jnp://cheetah:1099 cheetah cheetah hyena yes

stallion:1099 stallion cheetah hyena yes
http://stallion:1099 stallion cheetah hyena yes
rmi://stallion:1099 stallion cheetah hyena yes
jnp://stallion:1099 stallion cheetah hyena yes

hyena:1099 hyena cheetah hyena yes
http://hyena:1099 hyena cheetah hyena yes
rmi://hyena:1099 hyena cheetah hyena yes
jnp://hyena:1099 hyena cheetah hyena yes


The cases which fail (Success=no) all throw the same exception:
"java.rmi.NoSuchObjectException: no such object in table".

Failures only occur when JBoss, the Client, and the Service are all
running on the same machine. Moving any one of these pieces to a
different machine results in successful operation. Also note that if
JBoss, Client, and Service are on the same machine, only the "jnp"
protocol (or the default protocol, which I assume is jnp) fail.


My question is therefore - what's special about how JNP works when all
three pieces of this system are deployed on the same host?


- andy