[ 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: Closed >Resolution: Fixed 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-11 11:32 Message: Logged In: YES user_id=128193 Fixed in CVS, will be in next release. ---------------------------------------------------------------------- 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 ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285