6 Replies Latest reply on May 5, 2009 7:48 AM by kevenr

    JBoss 5 Client connect issues

    kevenr

      We are upgrading from the JBoss 4 series to JBoss 5. While working with JBoss 5, we have run into issues using remote clients.

      When we launch the app server, we are passing the "-b 0.0.0.0" flag. Connections to the server from the local machine are working fine.

      When we try to connect from a remote host using an initial context with the following InitialContext settings:

      env.setProperty(Context.INITIAL_CONTEXT_FACTORY,
       "org.jnp.interfaces.NamingContextFactory");
      env.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.naming.client");
      String providerUrl = "jnp://"+contextHost+":"+contextPort;
      env.setProperty(Context.PROVIDER_URL, providerUrl);


      For a remote connection, the contextHost will be the ip address of the remote JBoss instance. The context port is 1099.

      When I try to connect to the remote JBoss instance, I receive an exception back:
      javax.naming.NamingException: Could not dereference object [Root exception is org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [socket://localhost.localdomain:3873/?]]


      It appears that the server is telling the client to connect to it using localhost.localdomain, which happens to be the hostname of the remote machine (we do not use DNS or similar in our environment - shoot us). Of course, the client on the remote machine then attempts to connect to the localhost, which fails since there is no JBoss running on the client machine.

      As additional evidence, I set a hostname for the remote machine, and added it's IP address and host name in both the client and server's local lookup table (/etc/hosts). When I try to connect, everything works exactly as expected.

      In JBoss 4, we added the following JAVA_OPTS parameter to the run.conf to resolve this issue:
      -Djava.rmi.server.hostname=<ip address>

      This does not appear to work with JBoss 5.

      Is there a way around this, other than naming all of our machines, using DNS or similar? How can I tell the JBoss server to inform remote clients to use a specific IP address?

        • 1. Re: JBoss 5 Client connect issues
          peterj

           

          As additional evidence, I set a hostname for the remote machine, and added it's IP address and host name in both the client and server's local lookup table (/etc/hosts). When I try to connect, everything works exactly as expected.


          You found the fix. The host running JBoss AS must have its IP address and host name in its /etc/hosts file. In addition, the client system also needs that information in its /etc/hosts file.


          • 2. Re: JBoss 5 Client connect issues
            kevenr

            Does your response imply that this is the only "workaround", and that there is no plan to allow the overriding of this behaviour, or rather that this is a known issue, fix pending, but in the meantime, use this workaround?

            I'm hoping the later - in the environment presented to me, I simply cannot rely on network services being present and available, at least not at this time.

            Thanks for the confirmation, thought!

            • 3. Re: JBoss 5 Client connect issues
              peterj

              As far as I know, this is the only solution and no other solution is in development. From what I understand, it has to to with looking up the IP address for a host name, and vice versa. So the mapping has to be somewhere.

              By the way, you said you were upgrading from 4 to 5. Was that 4.0.x or 4.2.x? I ask because between 4.0.x and 4.2.0 the default binding was changed from 0.0.0.0 to 127.0.0.1. This could have something to do with this issue - ages ago one of my colleagues noticed that setting -b 0.0.0.0 in 4.2.x was not exactly the same as running 4.0.x without the -b option, though I do not recall the specific issue.

              • 4. Re: JBoss 5 Client connect issues
                kevenr

                We upgraded from 4.0.5.GA to 5.

                As a point of note, I was able to modify two files,
                deploy/ejb3-connectors-jboss-beans.xml
                and
                deploy/messaging/remoting-bisocket-service.xml

                In these files are references to

                ${jboss.bind.address}


                If these are replaced with another property (or hard-coded), then you remoting appears to work (at least for me). There are several other files in the deploy directory that reference the jboss.bind.address, and they may need to be configured if other portions of the J2EE specification need to be used. We are using JMS (topics), and EJB3 beans (stateless session, and POJO EJBs with hibernate to a MySQL DB).

                In my case, since I was already setting a system property "java.rmi.server.hostname" with the desired IP address, I used this, rather than hard-coding an IP address.

                I had found another document, http://www.jboss.org/community/docs/DOC-10733 that discusses the use of the -Djboss.bind.address. Unfortunately, I could not get remoting and local to work simultaneously in any configuration, almost as if the variable gets overwritten at some point internally.

                The good news is that these two modifications do not appear to break anything else. If someone wiser regarding the internals of JBoss could comment, it would be appreciated. Otherwise, we will go with these changes, for now.

                Thanks for the help!

                • 5. Re: JBoss 5 Client connect issues

                  We had the same problem. Our workaround is to start the jboss with the specific interface address instead of 0.0.0.0

                  -b 192.168.1.2

                  • 6. Re: JBoss 5 Client connect issues
                    kevenr

                    We tried that initially as well; however, IIRC, we then had issues connecting to JBoss from the local machine (127.0.0.1). Obviously, we had no issues connecting using the local machine's IP address.

                    The solution that I posted previously has worked successfully to date (and is somewhat parallel to the 4.0.5 solution used as well.).