What about if we add some configuration section (as a child node in the configuration) that can be used by any mediator, endpoint, proxy service, etc.
<aspect> <statistics> statistics policy </statistics> <trace> trace policy </ trace > <monitoring> monitoring policy </ monitoring> <reporting> reporting policy </reporting> …… </aspect> This might be useful in long-term if someone is going to develop tools for monitoring, deluging, reporting etc. for synapse . Thanks Indika On Fri, Dec 4, 2009 at 12:47 PM, Supun Kamburugamuva <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 >>>>> <[email protected]> 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:[email protected]] >>>>>> Sent: Thursday, December 03, 2009 9:17 PM >>>>>> To: [email protected] >>>>>> 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 >>>>>> <[email protected]> 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:[email protected]] >>>>>> Sent: Thursday, December 03, 2009 7:08 PM >>>>>> To: [email protected] >>>>>> 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 >>>>>> <[email protected]> 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:[email protected]] >>>>>> Sent: Wednesday, December 02, 2009 10:47 PM >>>>>> To: [email protected] >>>>>> 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: [email protected]; 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: [email protected]; cell: +94 77 341 3097 >> blog: http://ruwansblog.blogspot.com > > > > -- > Software Engineer, WSO2 Inc > http://wso2.org > supunk.blogspot.com > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
