Return-Path: Delivered-To: apmail-synapse-dev-archive@www.apache.org Received: (qmail 67421 invoked from network); 4 Dec 2009 08:37:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 Dec 2009 08:37:29 -0000 Received: (qmail 30275 invoked by uid 500); 4 Dec 2009 08:37:29 -0000 Delivered-To: apmail-synapse-dev-archive@synapse.apache.org Received: (qmail 30163 invoked by uid 500); 4 Dec 2009 08:37:28 -0000 Mailing-List: contact dev-help@synapse.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@synapse.apache.org Delivered-To: mailing list dev@synapse.apache.org Received: (qmail 30155 invoked by uid 99); 4 Dec 2009 08:37:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Dec 2009 08:37:28 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of indika.kuma@gmail.com designates 209.85.222.188 as permitted sender) Received: from [209.85.222.188] (HELO mail-pz0-f188.google.com) (209.85.222.188) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Dec 2009 08:37:25 +0000 Received: by pzk26 with SMTP id 26so2335598pzk.4 for ; Fri, 04 Dec 2009 00:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=fe5iBLLL6CCuz1MKr0jWDi239o2srEt8+QliHMs1jOU=; b=lGMz38NO5oaKnfx2RCF7f2X7DAmIAZXQjEbKPICMsYBuS9KylqJTnc6lQdILzlao/1 Q+Iudt81JiNB0ehNW8yQj7ytCETjBrp2IgE/GwPh7Ku2z2lV9g1gvgcsPPqf3vRmzAm9 Rlwf34ekaZ+B6LkPiEVEgTP0lSDT6uhIDZ5sw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=V/2lIzw/mGTBpAtCdmaqU0zNF4xp/jiU9MOMXto4qNQAilxYy4S2i630zaTTDN33ng fz3CJgXCUv701rFE8RLDhunPqiC5R7gTrjChEv+zpWHukAjz1r3RSkLofgi6cDThVxhF QdJEMZ+kPlBqyn77hEt1U/jclcaBWtKROoz5E= MIME-Version: 1.0 Received: by 10.140.136.19 with SMTP id j19mr190224rvd.187.1259915825339; Fri, 04 Dec 2009 00:37:05 -0800 (PST) In-Reply-To: References: <672a01200912031821j7d00bb2frc81bf725059292de@mail.gmail.com> <672a01200912032207h37fdb462rc2ea131d14c7795d@mail.gmail.com> Date: Fri, 4 Dec 2009 14:37:05 +0600 Message-ID: Subject: Re: JMX notifications for Endpoint state changes From: indika kumara To: dev@synapse.apache.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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. statistics policy trace policy monitoring policy reporting policy =85=85 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 wr= ote: > I was not thinking about the implementation. But since this is introducin= g a > new configuration, I was bit concerned. > > Supun.. > > On Thu, Dec 3, 2009 at 10:07 PM, Ruwan Linton > 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 >> 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 >>> 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 over= ride >>>> the global value at any configurable node, like on a sequence or endpo= int or >>>> even on a proxy. >>>> >>>> It is not clean if we bring this into the properties file, the XML mod= el >>>> that we use as the main configuration language allows you to nicely >>>> implement that. So this effects statistics collection and tracing as w= ell, >>>> 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 >>>> wrote: >>>>> >>>>> +1 for a global property and we can include it to the >>>>> synapse.properties file easily. But I'm also not sure about introduci= ng an >>>>> attribute to the endpoint configuration. >>>>> >>>>> Thanks, >>>>> Supun.. >>>>> >>>>> On Fri, Dec 4, 2009 at 2:30 AM, Hubert, Eric >>>>> wrote: >>>>>> >>>>>> Agreed, coupling statistics and notification would not be a good ide= a >>>>>> as we are talking about two non-related things. >>>>>> >>>>>> >>>>>> >>>>>> Regarding useful configurations options I would also need to think a >>>>>> bit more about it=85 >>>>>> >>>>>> Introducing an optional attribute on the endpoint level to turn the >>>>>> feature selectively on/off might (depending on the default) force th= e user >>>>>> having to set it on a large number of configuration items. >>>>>> >>>>>> Having a global switch (either on or off) plus the ability to overri= de >>>>>> the global option on the endpoint level may save configuration overh= ead and >>>>>> turn out to be more flexible, but could also make the configuration = harder >>>>>> to read/understand. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> =A0=A0 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 endpoi= nt then >>>>>> enable the notifications. But statistics and notifications are two d= ifferent >>>>>> 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 configura= tion? >>>>>> >>>>>> Thanks, >>>>>> Supun.. >>>>>> >>>>>> On Fri, Dec 4, 2009 at 1:33 AM, Hubert, Eric >>>>>> wrote: >>>>>> >>>>>> Hi Supun, >>>>>> >>>>>> >>>>>> >>>>>> You are welcome! Regarding my second point I think you are still abl= e >>>>>> to deliver some details, if you really like. If I remember correctly= there >>>>>> are actually three attributes type, message and userData, type and m= essage >>>>>> 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 cu= stom >>>>>> type. It has been a while since I last looked into this, but you may= at >>>>>> least want to check this=85 >>>>>> >>>>>> >>>>>> >>>>>> 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= =85 I=92m not >>>>>> quite sure if all users really do need this capability at all, altho= ugh I >>>>>> really see its value. So at least I would expect a switch to turn th= is >>>>>> feature completely on and off (also as part of an initial implementa= tion). >>>>>> The decision about activating the feature by default, or having the = user to >>>>>> activate it on demand =96 is of cause something different. What do o= thers >>>>>> think about this? >>>>>> >>>>>> >>>>>> >>>>>> Any =93more advanced=94 configuration could also follow later on =96= I >>>>>> agree. My idea was just a more practical one. Depending on how Synap= se is >>>>>> operated it might be the case that some of the endpoints are somehow >>>>>> =93expected=94 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 a= lert and >>>>>> which ones have to be ignored to don=92t flood the operational guys = with >>>>>> =93false positives=94. This could be realized by proper filtering. O= n the other >>>>>> hand generating lots of events useless events will impose some overh= ead >>>>>> which might be avoidable, if events are already fired selectively. T= his of >>>>>> cause only makes sense if the configuration is managed centrally alo= ng with >>>>>> the monitoring configurations. If this is done manually, most users = will >>>>>> probably prefer to filter on the client (monitoring) side. Just my p= ersonal >>>>>> 0.2 cents from both a users and a developer=92s perspective. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> =A0=A0 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 curr= ent >>>>>> state using a user defined notification. User can query the MBean an= d 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 configurati= ons. >>>>>> 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 t= he >>>>>> configuration, I'm +1 for implementing it. >>>>>> >>>>>> Thanks, >>>>>> Supun.. >>>>>> >>>>>> On Thu, Dec 3, 2009 at 1:32 PM, Hubert, Eric >>>>>> wrote: >>>>>> >>>>>> Hi Supun, >>>>>> >>>>>> >>>>>> >>>>>> I=92m +1 on the idea in general. There are at least two things which >>>>>> come immediately into my mind we probably should consider when (befo= re) >>>>>> 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=92m thinking on some decisions like this: >>>>>> >>>>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 only turn on/off event creation per typ= e (e.g. type >>>>>> endpoint marked as suspended) >>>>>> >>>>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 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 on= ly >>>>>> be interested to keep his monitoring configuration in one central pl= ace. >>>>>> 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 th= e >>>>>> Notification Object in his class path. So if using a non-standard ob= ject >>>>>> (e.g. a custom subclass of javax.management.Notification or non stan= dard >>>>>> objects stored inside the notification or one of its standard subcla= sses) we >>>>>> should always keep this in mind and think about its implications and= at >>>>>> least consider this in the artefact structure (created deployment un= its). >>>>>> Personally when working with JMX I always try to avoid non-standard = objects >>>>>> and restrict myself to standard types if possible. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> =A0=A0 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 ca= se >>>>>> of Endpoint state changes (i.e. marked as SUSPENDED) we can provide = JMX >>>>>> notifications. This allows users to take actions promptly without wa= iting >>>>>> for pulling the endpoint status data. I would like to know the opini= on 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