1 Reply Latest reply on Mar 10, 2004 11:05 AM by 101

    JNDI localhost problem

    Andy Gallo Newbie

      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

      Consider the following scenario:

      - There are three machines in this system: hyena, cheetah, and
      - 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();
      String jndiHost = System.getProperty("jndiHost",
      env.put(Context.PROVIDER_URL, jndiHost);

      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 hyena hyena hyena no hyena hyena hyena yes
      rmi:// hyena hyena hyena yes
      jnp:// hyena hyena hyena no hyena hyena hyena no hyena hyena hyena yes
      rmi:// hyena hyena hyena yes
      jnp:// 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

        • 1. Re: JNDI localhost problem
          101 Newbie

          could be related: when you do a new InitialContext() with localhost as the jndi provider then it will actually try to connec to the real ip address of the machine instead of

          i'm looking for a solution because if you run.sh --host localhost (to disallow connections from other hosts) then you can not shutdown.sh later as it will try to connect to the ip address instead of localhost ( which is rejected.