Hi Supun,

I’m +1 on the idea in general. There are at least two things which come 
immediately into my mind we probably should consider when (before) implementing 
this feature:
1) Configuration concept for event creation
2) Notification Object Type to use


1)
Here we should consider how configurable we want to keep the event creation. So 
I’m thinking on some decisions like this:
-          only turn on/off event creation per type (e.g. type endpoint marked 
as suspended)
-          or configurable per data object itself (e.g. on endpoint level) as 
part of the configuration language

Here I also see a trade off. On the one hand the user will likely only be 
interested to keep his monitoring configuration in one central place. 
Definitely he may not be interested in all kind of events. Of course there is 
always the chance of using a NotificationFilter.

2)
Depending on what information we want to distribute as part of an event object 
we should keep in mind that the client needs to have the Notification Object in 
his class path. So if using a non-standard object (e.g. a custom subclass of 
javax.management.Notification or non standard objects stored inside the 
notification or one of its standard subclasses) we should always keep this in 
mind and think about its implications and at least consider this in the 
artefact structure (created deployment units). Personally when working with JMX 
I always try to avoid non-standard objects and restrict myself to standard 
types if possible.

Regards,
   Eric




________________________________
From: Supun Kamburugamuva [mailto:supu...@gmail.com]
Sent: Wednesday, December 02, 2009 10:47 PM
To: dev@synapse.apache.org
Subject: JMX notifications for Endpoint state changes

Hi,

At the moment Synapse exposes endpoint statistics through JMX. In case of 
Endpoint state changes (i.e. marked as SUSPENDED) we can provide JMX 
notifications. This allows users to take actions promptly without waiting for 
pulling the endpoint status data. I would like to know the opinion of the 
community. The implementation is simple and if you agree on this I can provide 
a patch.

Thanks,
Supun..

--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com<http://supunk.blogspot.com>

Reply via email to