synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From indika kumara <indika.k...@gmail.com>
Subject Re: JMX notifications for Endpoint state changes
Date Fri, 04 Dec 2009 08:37:05 GMT
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 <supun06@gmail.com> 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 <ruwan.linton@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 <supun06@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.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
>>>
>>>
>>
>>
>>
>> --
>> 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
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org


Mime
View raw message