[ mx4j-Bugs-1004412 ] Client notification queue overflow
"SourceForge.net" <[email protected]>
| Newsgroups | gmane.comp.java.mx4j.devel |
|---|---|
| Message-ID | <[email protected]> |
Bugs item #1004412, was opened at 2004-08-06 09:02 Message generated for change (Comment added) made by biorn_steedom You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=450647&aid=1004412&group_id=47745 >Category: JSR 160 Implementation Group: Release 2.0.1 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Arend (eddi42) >Assigned to: Simone Bordet (biorn_steedom) >Summary: Client notification queue overflow Initial Comment: Hello, we use MX4J in a distributed environment. Our BeanServer holds a large number of MBeans (around 000), and the remote client registers a listener for each MBean. The MBeans are updated every 5 seconds creating a notification event for each update. Under this high load, the size of the client notification ueue (located in mx4j.remote.AbstractRemoteNotificationClientHandler$NotificationDelivererThread) grows steadily since the handlers do not work fast enough. One half of the solution is to make the handlers faster, but an intrinsic problem remains: the application has no possibility to control the notification queue. Since an OutOfMemoryError is thrown, the VM process is killed without ANY chance for error recovery. My proposal: - Add a (boolean) system key to enable queue control and an additional key to specify the maximum queue size - As an alternative, both properties may be combined: add numeric system key specifying the maximum queue size, with a value of 0 disabling queue control (and make it the default) - when the maximum size of the queue is reached, stop adding notifications and log at least an error message (I am not sure whether JMX specifies an apropriate error handling mechanism) Our application is a system monitoring solution controling the resources in a car production plant. The reliability of the application is extremely important; a potential loss of notifications is clearly preferable compared to a crash of he application. Regards, Thomas Arend ---------------------------------------------------------------------- >Comment By: Simone Bordet (biorn_steedom) Date: 2004-08-06 19:28 Message: Logged In: YES user_id=128193 Interesting, will do as suggested. If notifications are lost on client side, I will send a JMXConnectionNotification.NOTIFS_LOST notification to registered (and interested) connection listeners. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=450647&aid=1004412&group_id=47745 ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com