[ mx4j-Bugs-1554155 ] Timing hole in Monitor stop() start() processing

Bugs item #1554155, was opened at 2006-09-07 10:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=1554155&group_id=47745

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: JMX implementation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevan Miller (kevanm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Timing hole in Monitor stop() start() processing

Initial Comment:
I'm seeing occasional Monitor failures in some of the testing performed 
for Geronimo. The basic scenario is:

1) start Monitor
2) perform some processing
3) stop Monitor
4) sleep for a while
5) start Monitor
6) do some stuff...
7) test the number of Notifications

There is a timing window in the mx4j implementation. In certain cases, 
a notification can be scheduled for delivery after Monitor.stop() has 
been invoked. In this case, MX4J will set the notification status of the 
Monitor to true. If the Monitor is subsequently started (step 5 above), 
MX4J will not deliver a notification for the Monitor (because MX4J will 
mistakenly believe a notification has already been delivered).

Notification status is cleared in MX4JMonitor.stop(), which is a 
synchronized method. However, the scheduling of Notifications by
MX4JMonitor$MonitorTask.run() is unsynchronized and only checks 
Monitor state at the beginning of the method. So, there's a pretty large 
window for a Notification to occur after the Monitor has been 
stopped... 

The JMX specification is a bit fuzzy on the proper behavior for this 
scenario, but I'm pretty sure that a notification should always be 
delivered in this scenario after step 5. As a user, I would expect a 
notification and my interpretation of the intent of the mx4j 
implementation is to always deliver a notification in this case...

A true fix is to synchronize the stop/start and notification processing 
for Monitors. A less robust, but likely to fix my problem, solution 
would be to always clear the notifcation status for a monitor when 
*starting* the monitor (not just when stopping).

Happy to work up the fix for this and/or test... Just let me know...


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

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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642