Hi Ruwan, I think if we do this the correct way, the way you've suggested is the correct way. I was bit reluctant to do that because it is kind of like a big change. At least at the conceptual level.
I like your idea and I'll come up with an implementation. Eric, What do you think? Thanks, Supun.. On Thu, Dec 3, 2009 at 6:21 PM, Ruwan Linton <ruwan.lin...@gmail.com> wrote: > Supun, > > I see a real value of Eric's suggestion. We could introduce three > attributes called "statistics", "trace", and "notifications" in to the > definitions tag level, so those are the global values and you may override > the global value at any configurable node, like on a sequence or endpoint or > even on a proxy. > > It is not clean if we bring this into the properties file, the XML model > that we use as the main configuration language allows you to nicely > implement that. So this effects statistics collection and tracing as well, > which can be turned on and off at a global level instead for the > notifications. > > Thanks, > Ruwan > > > On Fri, Dec 4, 2009 at 4:54 AM, Supun Kamburugamuva <supu...@gmail.com>wrote: > >> +1 for a global property and we can include it to the synapse.properties >> file easily. But I'm also not sure about introducing an attribute to the >> endpoint configuration. >> >> Thanks, >> Supun.. >> >> >> On Fri, Dec 4, 2009 at 2:30 AM, Hubert, Eric >> <eric.hub...@foxmobile.com>wrote: >> >>> Agreed, coupling statistics and notification would not be a good idea >>> as we are talking about two non-related things. >>> >>> >>> >>> Regarding useful configurations options I would also need to think a bit >>> more about it… >>> >>> Introducing an optional attribute on the endpoint level to turn the >>> feature selectively on/off might (depending on the default) force the user >>> having to set it on a large number of configuration items. >>> >>> Having a global switch (either on or off) plus the ability to override >>> the global option on the endpoint level may save configuration overhead and >>> turn out to be more flexible, but could also make the configuration harder >>> to read/understand. >>> >>> >>> >>> Regards, >>> >>> Eric >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> >>> *From:* Supun Kamburugamuva [mailto:supu...@gmail.com] >>> *Sent:* Thursday, December 03, 2009 9:17 PM >>> >>> *To:* dev@synapse.apache.org >>> *Sub* >>> *ject:* Re: JMX notifications for Endpoint state changes >>> >>> >>> >>> HI Eric, >>> >>> I can understand your suggestion about turning notifications on/off >>> selectively. One thing is if the statistics are enabled for a endpoint then >>> enable the notifications. But statistics and notifications are two different >>> things. So that may be not good. Any ideas from the community how to do >>> this? May be we can introduce an attribute to the endpoint configuration? >>> >>> Thanks, >>> Supun.. >>> >>> On Fri, Dec 4, 2009 at 1:33 AM, Hubert, Eric <eric.hub...@foxmobile.com> >>> wrote: >>> >>> Hi Supun, >>> >>> >>> >>> You are welcome! Regarding my second point I think you are still able to >>> deliver some details, if you really like. If I remember correctly there are >>> actually three attributes type, message and userData, type and message being >>> String and type being Object. So you can still use userData to add more >>> detail which should not go into the message. The only thing is that the type >>> of the user data should be some standard Object and not some custom type. It >>> has been a while since I last looked into this, but you may at least want to >>> check this… >>> >>> >>> >>> Regarding my first point I assumed you would already have some user >>> requirements in mind as most of the time this is the starting point… I’m not >>> quite sure if all users really do need this capability at all, although I >>> really see its value. So at least I would expect a switch to turn this >>> feature completely on and off (also as part of an initial implementation). >>> The decision about activating the feature by default, or having the user to >>> activate it on demand – is of cause something different. What do others >>> think about this? >>> >>> >>> >>> Any “more advanced” configuration could also follow later on – I agree. >>> My idea was just a more practical one. Depending on how Synapse is operated >>> it might be the case that some of the endpoints are somehow “expected” to be >>> suspended from time to time whereas others are expected to be 100% stable. >>> Normally monitoring configuration is handled in one central place. The >>> configuration knows about what events shall generate an alert and which ones >>> have to be ignored to don’t flood the operational guys with “false >>> positives”. This could be realized by proper filtering. On the other hand >>> generating lots of events useless events will impose some overhead which >>> might be avoidable, if events are already fired selectively. This of cause >>> only makes sense if the configuration is managed centrally along with the >>> monitoring configurations. If this is done manually, most users will >>> probably prefer to filter on the client (monitoring) side. Just my personal >>> 0.2 cents from both a users and a developer’s perspective. >>> >>> >>> >>> Regards, >>> >>> Eric >>> >>> >>> >>> >>> ------------------------------ >>> >>> *From:* Supun Kamburugamuva [mailto:supu...@gmail.com] >>> *Sent:* Thursday, December 03, 2009 7:08 PM >>> *To:* dev@synapse.apache.org >>> *Subject:* Re: JMX notifications for Endpoint state changes >>> >>> >>> >>> 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 >>> >>> >>> >>> >>> -- >>> Software Engineer, WSO2 Inc >>> http://wso2.org >>> supunk.blogspot.com >>> >>> >> >> >> -- >> Software Engineer, WSO2 Inc >> http://wso2.org >> supunk.blogspot.com >> >> >> > > > -- > Ruwan Linton > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb > WSO2 Inc.; http://wso2.org > email: ru...@wso2.com; cell: +94 77 341 3097 > blog: http://ruwansblog.blogspot.com > -- Software Engineer, WSO2 Inc http://wso2.org supunk.blogspot.com
