Hi Eric, Thanks for the suggestions.
I like your second idea. In Endpoint case I think we can avoid using a User defined notification. We simply send a notification of type synapse.endpoint.state.change. We don't need to say what is the current state using a user defined notification. User can query the MBean and figure out what is the current state. My personal opinion about your first idea is we should consider it after the initial implementation depending on the user requirements. This gives us time to think about the correct way to have the configurations. Still I don't have a clear understanding about how to configure this. So my initial plan was to enable it for all the endpoints as in the normal JMX case. If we can come up with a correct sensible way to introduce this to the configuration, I'm +1 for implementing it. Thanks, Supun.. On Thu, Dec 3, 2009 at 1:32 PM, Hubert, Eric <eric.hub...@foxmobile.com>wrote: > 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 > > -- Software Engineer, WSO2 Inc http://wso2.org supunk.blogspot.com
