looking at the code, I think the timer should override the sendNotification() to use multiple threads to call listener handleNotification() methods (threadpool if it seems creating new Threads per listener call won't perform, which is likely)
however the default behavior in the notificationbroadcaster support should be left as is imho, iow similar to java event handling ideally we could just drop in a different nb support implementation but since the spec forces us to subclass the default implementation instead of just implementing the notificationbroadcaster interface this seems the way to go about it I leave the decision for Adrian though, it is his code :) -- Juha On Tue, 9 Apr 2002, Andreas Schaefer wrote: > Hi Corby > > Thanx for looking into it. Will check with Juha / Adrian to see what they > think. > > > 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. > > Currently I don't think we should fix it on the Scheduler level. The problem > is that even when the Scheduler > does not delay the call there can be another listener which does not go > along with this. > If we can fix this on JMX level then do it this way. > > Andy > > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > -- Juha Lindfors Author of "JMX: Managing J2EE with Java Management Extensions" Senior Developer, JBoss Group LLC _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
