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

[davetron5000]

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)

[adrian.brock]

Sounds like a dns/host config issue to me.

[davetron5000]

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?

[adrian.brock]

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.

[davetron5000]

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>

[davetron5000]

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?

[davetron5000]

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.

[adrian.brock]

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

[hbaxmann]

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

anymore anywhere?

bax

[jdbrown]

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.