I was not thinking about the implementation. But since this is introducing a new configuration, I was bit concerned.
Supun.. On Thu, Dec 3, 2009 at 10:07 PM, Ruwan Linton <ruwan.lin...@gmail.com>wrote: > 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 > -- Software Engineer, WSO2 Inc http://wso2.org supunk.blogspot.com
