Supun, It is not going to be a that big change, you just need to change the implementation of isStatisticsEnabled and isTracingEnabled method to look for the global flag if it is not set at the respective component.
and you need to modify the synapse configuration builder to look at the definitions tag and set the global values of these. Thanks, Ruwan On Fri, Dec 4, 2009 at 9:42 AM, Supun Kamburugamuva <supu...@gmail.com>wrote: > 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 > > > -- 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
