Re: RemoteNotificationClientHandler fix

Bordet, Simone wrote:
> BTW, the fetcher thread is a strange beast. From my first
> experiments, it turn out that you cannot stop an RMI call that is
> pending on the server side (as it is the fetchNotification() call: it
> is waiting a timeout on the server). Calling Thread.interrupt() does
> not throw an InterruptedIOException, but I have to investigate more.

In general, Thread.interrupt is not guaranteed to interrupt an ongoing 
I/O operation.  (It happens to do so on Solaris, but not on Linux or MS 
Windows for example.)  I'm not familiar with the details of the MX4J RMI 
connector, but it looks like one solution would be to include a smallish 
value for the timeout parameter in the fetchNotifications call.  At 
worst, the call will return after that timeout, and presumably the 
fetcher thread will then notice that the connection is closed and 
return.  This also gives you a heartbeat for free, at least on 
connections that have listeners.

I am not sure why you have a problem, anyway.  When the server closes a 
connection, it should cause an ongoing fetchNotifications call to return 
immediately with zero notifications.  It shouldn't let that call run to 
timeout.

-- 
Éamonn


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&op=click