[ 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.