synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Supun Kamburugamuva <supu...@gmail.com>
Subject Re: JMX notifications for Endpoint state changes
Date Fri, 04 Dec 2009 04:12:37 GMT
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.linton@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 <supun06@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.Hubert@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:supun06@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.Hubert@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:supun06@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.Hubert@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:supun06@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: ruwan@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>



-- 
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

Mime
View raw message