[timfox]

It should be calling this:

http://java.sun.com/javase/6/docs/api/java/net/Socket.html#setSoTimeout%28int%29

[gaohoward]

Hi Andy,

I haven't done some really test. Hopefully I can do it this week. I'm using HornetQ's jms-bridge to prepare the tests.

By the way, did you try any 'soft' unplugging like Tim suggested using "/sbin/ifconfig eth0 down" command? I wonder if this has the same effect as the physical unplugging the cable.

I'll let you know my result.

Howard

[ataylor]

Ok, so it turns outthatthe timeout settings only ever get used for the initial connection and RMI is used for the rest, it goes something like this:

1. Create a socket and set sotimeout

2. call sockent connect with timeout

3. Marshall the Naming Server Stub

4. close the connection

5. invoke lookup on Naming Server Stub (RMI call)

Note, once the stub is downloaded it is cached, subsequent calls use the cached stub.

So if the network cable is unplugged at step 5 then the RMI default timeouts are used. As far as i can see this is 18 seconds for the read timeout and 10 seconds for subsequent connect time outs. The default time outs are specific to the RMI implementation, we use Sun's which can be found at http://java.sun.com/j2se/1.5.0/docs/guide/rmi/sunrmiproperties.html however i tried most of these and none of them seemed to make any difference.

[ataylor]

So i will update all the bridge examples etc to set the jnp timeouts and document this along with the RMI timeouts.

[gaohoward]

Update:

I did a test and I couldn't see the bridge hang. When I unplug the cable, the bridge keeps trying. After about 10 min, I re-plug in the cable, the network restored quickly and the bridge resume working.

Both machines sit in one LAN. HornetQ version is 2.1.1.Final.

[timfox]

The idea was to replicate the issue by writing a simple test client which does JNDI lookups in a loop.

To replicate this issue the timing needs to be right - you would need to interrupt the network in the middle of downloading an object in JNDI.

Timing that right with the bridge would be very hard to do, which probably explains the difficulty in replicating it.

[ataylor]

Howard, see my previous post, ive added timeouts and updated the docs

[gaohoward]

As far as i can see this is 18 seconds for the read timeout and 10  seconds for subsequent connect time outs.

Andy, if it has default timeouts, how come the JNDI lookup ever hang?

[ataylor]

Yong Hao Gao wrote:

As far as i can see this is 18 seconds for the read timeout and 10  seconds for subsequent connect time outs.

Andy, if it has default timeouts, how come the JNDI lookup ever hang?

Yes, thats the default for sun's RMI implementation. Maybe he wasn't waiting long enough, i know i was only waiting for the 5 second time out i had set on the jndi layer.