3 Replies Latest reply on Jun 20, 2004 2:49 AM by bruciadmin

    Potential Bug when looking up on localhost

    bruciadmin

      Hi There,

      I hope this is the right place to post this, I think I've found a bug with the naming component of JBoss 3.2.4. I've tested with JDK 1.4.2_02 and 1.4.2_04. This problem was not in the previous version we were using (3.2.3) and was discovered initially upon upgrade. The problem seems to manifest when I configure the JBoss servers JNDI bound interface to the loopback (localhost).

      It appears that JBoss itself is working, but the lookup is failing (the client code, not the server). Every attempt to lookup the home interface results in the following:

      javax.naming.CommunicationException [Root exception is java.rmi.ConnectException: Connection refused to host: 192.168.X.X; nested exception is:
      java.net.ConnectException: Connection refused: connect]
      at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:647)
      at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507)
      at javax.naming.InitialContext.lookup(InitialContext.java:347)
      at au.com.distillery.iqore.utilities.ejb.test.JNDILookupTest.testJNDILookup(JNDILookupTest.java:43)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:324)
      at junit.framework.TestCase.runTest(TestCase.java:154)
      at junit.framework.TestCase.runBare(TestCase.java:127)
      at junit.framework.TestResult$1.protect(TestResult.java:106)
      at junit.framework.TestResult.runProtected(TestResult.java:124)
      at junit.framework.TestResult.run(TestResult.java:109)
      at junit.framework.TestCase.run(TestCase.java:118)
      at junit.framework.TestSuite.runTest(TestSuite.java:208)
      at junit.framework.TestSuite.run(TestSuite.java:203)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:392)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:276)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:167)
      Caused by: java.rmi.ConnectException: Connection refused to host: 192.168.1.26; nested exception is:
      java.net.ConnectException: Connection refused: connect
      at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:567)
      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)
      ... 18 more
      Caused by: java.net.ConnectException: Connection refused: connect
      at java.net.PlainSocketImpl.socketConnect(Native Method)
      at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
      at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
      at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
      at java.net.Socket.connect(Socket.java:452)
      at java.net.Socket.connect(Socket.java:402)
      at java.net.Socket.(Socket.java:309)
      at java.net.Socket.(Socket.java:124)
      at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)
      at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)
      at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:562)
      ... 23 more


      For a long time I tested various scenarios, and everything points to an error on the client. I've tested this against a fresh jboss installation with only one change to the configuration (the bind interface for JNDI is localhost). I eventually got annoyed enough to write a simple testcase which I've included below.

      public class JNDILookupTest extends TestCase
      {
      public void testJNDILookup() {
      Context ctx = null;
      Hashtable ht = new Hashtable();
      ht.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
      ht.put(Context.PROVIDER_URL, "jnp://localhost:1099");
      CommandManagerHome home = null;
      try {
      ctx = new InitialContext(ht);
      String lookupClassName = CommandManagerHome.class.getName();
      home = (CommandManagerHome) ctx.lookup(lookupClassName);
      } catch (Exception e) {
      e.printStackTrace();
      } finally {
      try {
      ctx.close();
      } catch (Exception e) { }

      }
      assertTrue(home != null);

      }
      }


      Please help or confirm the issue, a workaround isn't hard to implement (just don't use localhost) but I would rather not.

      Thanks,

      David L

        • 1. Re: Potential Bug when looking up on localhost
          starksm64

          There is not difference between 3.2.3 and 3.2.4 in this regard. The naming service rmi port is not being bound to the specified interface. You can override this interface by setting the java.rmi.server.hostname system property to localhost.

          • 2. Re: Potential Bug when looking up on localhost
            ronaldoc

            bruciadmin,

            Not sure what platform you're running JBoss on but if its Linux, make sure your iptables setting is allowing connection to port 1099. Nevertheless, post your solution here if it was caused by something else.

            Regards,

            Ronaldo

            • 3. Re: Potential Bug when looking up on localhost
              bruciadmin

              Thanks heaps,

              This was the problem (the first answer with the JVM property).

              It seems that when I was upgrading the installations and transferring the customizations we'd made to 3.2.3 startup scripts, I made a silly mistake with customizing the JAVA_OPTS variable. Instead of the usual windows property setting, "set VAR=VALUE", I suffered an attack of windows/unix dislexia and put in "VAR=VALUE".

              What this meant was that the rmi variable not being set, which is exactly what you thought it was.

              Sorry for posting this as a bug, I guess I'll be eating some bad tasting humble pie for a week or more.

              Cheers,

              David L