RE: RemoteNotificationClientHandler fix

Hi,

> 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 thought this was true in JDK 1.3, but clarified in 1.4. I can't recall from where I got this impression.

> 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.

Sure, the timeout is configurable via a system property.

> 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.

...and thanks, I missed that, and it's probably missing from the code.
I'll check now.

Regards,

Simon


-------------------------------------------------------
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