Hi, I finally got chance to look at this. You are correct with your analysis of the Timer service and the NotificationBroadcaster. But I don't think this affects the Scheduler. It only registers one listener with the timer. If you want a second MBean, you create a second scheduler which in turn creates a new timer notification id. The timer notifications from different ids are already concurrent.
Multi-threading the broadcaster on a slow listener could introduce either a large backlog of notification objects or thread death depending on whether the broadcaster synchronizes the listener. After consideration, I think it is correct to register different timer notification ids if you want concurrent notifications. With this constraint, the number of notification objects and threads never exceeds the number of registered notification ids. In summary, for concurrent notifications create a second scheduler. Regards, Adrian >I looked at the new JBossMX stuff; Juha's rewrite of >the Timer has fixed part of the problem. He does a >much better job than Sun's Timer of determining what >the next call time should be, and so in the example I >gave he will attempt to execute the second MBean >invocation at 12:00:30 rather than 12:00:35. > >However, there is still a problem that originates in >the javax.management.NotificationBroadcasterSupport >class (which Juha has also rewritten). In the >sendNotification method, he iterates through the set >of NotificationListeners and does a synchronous >notification to each Listener in the list. It appears >that this single-threaded approach will prevent the >Timer from effecting a notification to any MBean if >the last-notified MBean has not yet finished >executing its scheduled method. > >In the example I gave before, assume there is a >second MBean, and it also has a InitialStartDate of >12:00:00 and a SchedulePeriod of 30 seconds. If the >first MBean takes 5 seconds to complete its scheduled >invocation, then the second MBean will execute at >12:00:05, and 12:00:35, and so on. > >My patch addresses this problem without altering >NotificationBroadcastSupport. The SchedulerMBean >receives the synchronous notification, creates a new >Thread to actually invoke the MBean, and returns the >original Thread of control back to the Timer so that >it can immediately fire the next notification. > >Anyway, let me know if you'd like the patch. It might >be faster for you to just code the fix yourself. > >Corby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
