[ mx4j-Bugs-902819 ] Fetcher thread in RemoteNotificationClientHandler never ends

Bugs item #902819, was opened at 2004-02-23 17:56
Message generated for change (Comment added) made by biorn_steedom
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=902819&group_id=47745

Category: JSR 160 Implementation
Group: Release 2.0.0
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Chris Arrington (cdarring)
Assigned to: Brian Scully (btscully)
Summary: Fetcher thread in RemoteNotificationClientHandler never ends

Initial Comment:
Submitter: Chris Arrington ([email protected])

Summary: RemoteNotificationClientHandler fetcher 
thread for remote notifications does not end after 
JMXConnectorServer is shutdown either gracefully or 
forcefully, using MX4J 2.0 beta 1.

Detail: When NotificationListeners are added via a 
remote MBeanServerConnection, tuples are added to a 
local Map with the listener objects. A fetcher thread is 
then started that polls the JMXConnectorServer 
periodically for notifications. This thread is ended ONLY 
as soon as all NotificationListeners are removed 
(RemoteNotificationClientHandler.java lines 133-135), 
based on the number of tuples (NotificationListener 
objects) in the Map. Ending the fetcher thread means 
that the user must be able to detect the lost 
connection, have all references to the 
NotificationListeners, and remove them all upon 
detecting the lost connection.

Even if the user were able to detect the lost 
connection, the order of calls in ClientInvoker (lines 91-
92) is such that the remote processing is called before 
the local processing which removes the 
NotificationTuples, which is what will allow for the ending 
of the fetcher thread. However, when the 
JMXConnectorServer is no longer up, the removal will not 
proceed past the remote processing, and the 
NotificationListeners cannot be removed. At the very 
least, if remote and local processing were reversed, 
there would be a possibility for ending the fetcher thread.

----------------------------------------------------------------------

>Comment By: Simone Bordet (biorn_steedom)
Date: 2004-02-24 11:02

Message:
Logged In: YES 
user_id=128193

Brian, the fix is kinda hacky, but the idea is good.
It is maybe worth to add start() and stop() to the
RemoteNotificationClientHandler interface, and invoke them
directly like your fix suggested.

One thing that's not clear to me is what should we do with
registered listeners, if we should remove them all, or leave
them. I have posted a request for clarification to the JSR
160 Expert group, the answer should come soon.

For the time being, I'll reopen the bug, we will discuss the
fix in detail on mx4j-dev.

Thanks !

----------------------------------------------------------------------

Comment By: Brian Scully (btscully)
Date: 2004-02-24 04:28

Message:
Logged In: YES 
user_id=234750

Thanks for reporting the bug.  A preliminary fix has been 
made to CVS HEAD.  Now the threads will stop upon closing 
the JMXConnector.  I haven't closed the case because I am 
not sure that this fully addresses the issue that you are 
having.  I think you are suggesting ( correct me if i'm wrong ) 
that you want to see a shutdown of these threads when the 
remote JMXConnectorServer is stopped.

If the preliminary fix doesn't meet your needs, reply here - 
and i'll see what I can do.  I will hold the case open for a 
little while, but get back to me when you can - we're trying 
to wrap things up before the 2.0 release.

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=902819&group_id=47745


-------------------------------------------------------
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_id=1356&alloc_id=3438&op=click