9 Replies Latest reply on Jun 21, 2004 4:03 PM by Jeff Brown

    context.lookup takes 7+ _seconds_ to return over LAN on Wind

    David Copeland Newbie

      Basic setup is JBoss 3.2.3, default server, no config changes (save a datasource).

      Swing client makes Stateless Session EJB calls.

      On linux (RedHat 9.0), EJB calls behave normally; context is created, lookup occurs quickly, call proceeds normally.

      On both Windows 2000 and Windows XP, same subnet, same JRE version, same application, the call to InitialContext.lookup() used to get the EJB Home interface takes over 7 seconds. Yes, that's seconds. 7000+ milliseconds.

      Same machine, same code agains Weblogic 6 is sub-1 second and not noticeable.

      Both clients use jbossall-client.jar

      There's no log information related to this in any log.

      This happens for every EJB that is looked up, regardless of how many times it has been accessed in the past.

      Questions:

      1. What's my next step in identifying the problem?

      2. Is there a Windows-specific version of the jboss client jar, or an otherwise better client jar that may alleviate some of this?

      3. Is there a way to configure the server (or client) to improve performance or even cache things? (I believe a cache is the wrong solution here as 7 seconds seems excessive and indicates a configuration problem on my end)

        • 1. Re: context.lookup takes 7+ _seconds_ to return over LAN on
          Adrian Brock Master

          Sounds like a dns/host config issue to me.

          • 2. Re: context.lookup takes 7+ _seconds_ to return over LAN on
            David Copeland Newbie

            I forgot to specify that I'm not using DNS. We're using the IP address. Furthermore, this behavior occurs on every Windows box on our LAN (at least all those where we've tried it), and on none of the Linux boxes on our LAN.

            Is there something else I can check?

            What happens during the lookup that could cause a bottleneck? Am I using the appropriate client jar for what I'm doing?

            • 3. Re: context.lookup takes 7+ _seconds_ to return over LAN on
              Adrian Brock Master

              Try adding TRACE logging for org.jnp (this is the naming category),
              it might show something useful.

              You should also look at installing some packet sniffers/network monitoring
              so you can see which network requests are taking time. I still think a host lookup
              timeout is the most likely cause.

              Try doing the initial stage of the lookup yourself:
              telnet server-ip 1099

              Have you been through the FAQs? e.g. /etc/hosts

              Like I've said many times before, these forums are NOT network support forums.
              Your network adminstrator is responsible for your network problems.

              • 4. Re: context.lookup takes 7+ _seconds_ to return over LAN on
                David Copeland Newbie

                OK, part of my problem seems to be that JBoss sends, to the client, a URL like

                http://hostname:8083/

                and in the log, this appears as:

                Using RMI Server codebase: http://hostname:8083

                It seems to be happening during the JNDI handshaking process (presumably JBoss is telling the client where to go for RMI calls)

                Why this is a problem is that "hostname" is not in DNS (and, for my case, cannot ever be). Furthermore, the machine in question must be named "hostname" (don't ask).

                I am not sure where it gets this from, so I created a SystemPropertiesService MBean in jboss-service.xml (xml below) to set the property jboss.bind.address to be my ip address.

                This did not have any effect on the RMI Server codebase, nor my problem. The change DID have an effect, as anywhere in the logfile that '0.0.0.0' showed up, my ip address now shows up; just not for the RMI Server codebase (or what is getting sent to the client). I figure as long as JBoss is sending over an invalid hostname (invalid to the client that is), then all bets are off regarding my problem. The linux vs. windows things is coincidental, because our linux boxes have the servername in question in their /etc/hosts, whereas windows boxes do not.

                So, how can I control the hostname that the RMI server codebase uses without modifying the network configuration of my machine?

                XML:

                 <mbean code="org.jboss.varia.property.SystemPropertiesService"
                 name="jboss.util:type=Service,name=SystemProperties">
                 <attribute name="Properties">
                 jboss.bind.address=156.9.155.141
                 </attribute>
                 </mbean>
                


                • 5. Re: context.lookup takes 7+ _seconds_ to return over LAN on
                  David Copeland Newbie

                  BTW, it seems that the WebService MBean controls the RMI Codebase, and it's "Host" attribute controls the 'name of the public interface'. This is set to ${jboss.bind.address} and as such I would expect it to get my IP address as its value, based on my system properties MBean setup. Appears that is not the case, or I'm missing some other location where it's set?

                  • 6. Re: context.lookup takes 7+ _seconds_ to return over LAN on
                    David Copeland Newbie

                    OK, so sorry to be posting 8000 messages, but I solved my problem, and I believe that it was the result of a bug in JBoss that I was thankfully able to workaroud.

                    In org.jboss.web.WebService there is a method:

                    protected void startService() throws Exception
                     {
                     // Host must be set to continue (either by user or detection)
                     String address = getHost();
                     if (address == null)
                     throw new MissingAttributeException("Host");
                    
                     // Start the WebServer running
                     server.start();
                     log.info("Started WebServer with address: " + server.getBindAddress() + ":" + getPort());
                    
                     // Set the rmi codebase if it is not already set
                     String codebase = System.getProperty("java.rmi.server.codebase");
                     if (codebase == null)
                     {
                     address = ServerConfigUtil.fixRemoteAddress(address);
                    
                     codebase = "http://" + address + ":" + getPort() + "/";
                     System.setProperty("java.rmi.server.codebase", codebase);
                     }
                     log.info("Using RMI server codebase: " + codebase);
                     }
                    


                    What happens is that if you do not set the system property in question, it uses your configured host (which, by default is jboss.bind.hostname system property). That is reasonable and correct.

                    THEN, it puts the address through ServerConfigUtil.fixRemoteAddress, which turns your host address into a servername. This, IMHO, is incorrect behavior. At least, it seems incorrect when you've specified the jboss.bind.address to be something other than the default. Names are for humans. Numbers are for machines. The number is always correct, wheras the name is dependant on the DNS server and client configuration, and introducing this dependancy by default seems wrong. Maybe this is addressed in a later version, but FYI, the solution was to set

                    java.rmi.server.codebase=http://my_ip_address:8083/

                    in my SystemPropertiesService MBean.

                    If there's a bug tracker for JBoss, I'll submit this if anyone agrees with me.

                    • 7. Re: context.lookup takes 7+ _seconds_ to return over LAN on
                      Adrian Brock Master

                      While I generally agree with you about names and numbers, it is too naive
                      for more complicated network configurations.

                      e.g.
                      1) If you are using a firewall, although the firewall will rewrite the packet headers to
                      translate ip addresses, it will not rewrite ip addresses embedded in the packet bodies
                      (like the RMI codebase)

                      2) If your machine is multi-homed with NICs accessing networks that cannot see
                      each other, you cannot send the ip address to the client, because it will be wrong on
                      one of the networks.

                      3) The default configuration binds to all ip addresses 0.0.0.0 (which is useless to a client)

                      Where I will agree with you is that if you do specify an ip address, it shouldn't then
                      change over to using the host name.

                      Bug reports (as mentioned in the faq): www.sf.net/projects/jboss

                      • 8. Re: context.lookup takes 7+ _seconds_ to return over LAN on
                        Holger Baxmann Novice

                        Thank you Adrian, now I have some arguments for "Why need we one DNS for our network?" field expierience question.

                        anymore anywhere?

                        bax

                        • 9. Re: context.lookup takes 7+ _seconds_ to return over LAN on
                          Jeff Brown Newbie

                          I had a similar problem - Swing app accessing Session bean worked fine on local network but performance degraded quite a bit when deployed using JNLP over a VPN. I was using IP addresses as the provider URL back to the server, but a sniffer showed a bunch of UDP traffic based on the host name and unsuccessful host name lookups.

                          Implemented above solution and works great over the VPN - thanks.