On Mon, Feb 1, 2010 at 12:44 AM, Ruwan Linton <[email protected]>wrote:
> > > On Sun, Jan 31, 2010 at 7:58 PM, Hiranya Jayathilaka <[email protected] > > wrote: > >> >> >> On Sun, Jan 31, 2010 at 6:07 PM, Ruwan Linton <[email protected]>wrote: >> >>> I think think we should support hierarchical configuration, even for >>> markForSuspension. When you configure a set of endpoints into a failover >>> endpoint, if you want all the endpoints to be configured in a given single >>> manner use should be able to do it at the parent endpoint level, and define >>> any specific configuration at the leaf endpoint to override the >>> configuration provided to itself by its parent. >>> >> >> +1 to the idea in general >> >> >>> >>> We have once discussed a similar model for statistics, tracing and other >>> aspects for the whole config model, I see this as the same. >>> >>> In a way this actually belongs to the leaf endpoint, where as I should be >>> able to configure the retry configuration of an individual endpoint with >>> reference to the failedMessage configuration that Rajika proposed. So from >>> my point of view this is same as markForSuspension, and should belong to >>> both levels. >>> >> >> Does this configuration element has any meaning for an individual leaf >> endpoint? Does it offer any functionality when the endpoint is not wrapped >> inside a failover endpoint? If it has any significance for an individual >> leaf endpoint, then yes - It has to be a leaf endpoint configuration. But I >> think Rajika mentioned that this configuration becomes meaningful only when >> the leaf endpoint is wrapped in a failover endpoint. In that case it doesn't >> make much sense to have it as a leaf endpoint configuration element. >> > > Hiranya, > > I am thinking out of the solution that Rajika explained, individual leaf > endpoints have a concept called retry right? Which is basically not failover > but re-tries the same endpoint, so for re-trying as well, we should be able > to define what is a failed message, in which case this will be important in > the leaf endpoint as well. > +1 > I agree with Rajika's original proposal there is no meaning for keeping it > at leaf endpoint level, but if we implement the above it actually has a > meaning. > As long as this configuration offers some functionality for individual leaf endpoints it is fine to configure at that level. Thanks, Hiranya > Thanks, > Ruwan > >> >> Thanks, >> Hiranya >> >> >>> Thanks, >>> Ruwan >>> >>> >>> On Sun, Jan 31, 2010 at 4:28 PM, Hiranya Jayathilaka < >>> [email protected]> wrote: >>> >>>> Hi Rajika, >>>> >>>> Please see my comments inline. >>>> >>>> On Sun, Jan 31, 2010 at 3:37 PM, Rajika Kumarasiri <[email protected]>wrote: >>>> >>>>> >>>>> >>>>> On Sun, Jan 31, 2010 at 12:27 PM, Supun Kamburugamuva < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Sun, Jan 31, 2010 at 11:10 AM, Hiranya Jayathilaka < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Rajika, >>>>>>> >>>>>>> On Sun, Jan 31, 2010 at 9:31 AM, Rajika Kumarasiri >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> hi, >>>>>>>> Right now in a failover scenario Synapse will try to re-send the >>>>>>>> message to the next available active endpoint ( this depend on the >>>>>>>> failover >>>>>>>> algorithm in use). For example if the 1st endpoint receives a timeout >>>>>>>> error >>>>>>>> or a connection refused error Synapse will try to send the message to >>>>>>>> the >>>>>>>> next available endpoint. There are requirements in which case if we >>>>>>>> receive >>>>>>>> a particular error( for ex: a connection timeout) from the 1st >>>>>>>> endpoint we >>>>>>>> don't want to try the second available endpoint but just drop the >>>>>>>> message(or >>>>>>>> send a fault back). For ex: in a failover scenario we'll need to drop >>>>>>>> the >>>>>>>> message without trying the 2nd endpoint if we receive a connection >>>>>>>> timeout >>>>>>>> error but we'll need to try the next available endpoint if we receive a >>>>>>>> connection refused error. Right now Synpase doesn't have this >>>>>>>> capability. >>>>>>>> >>>>>>>> So I'd like to suggest the following configuration for leaf >>>>>>>> endpoints(Address/WSDL) which only be valid in a failover scenario. >>>>>>> >>>>>>> >>>>>>> I don't think it's a good idea to have this configuration at leaf >>>>>>> endpoint level if it is only valid when the leaf endpoint is wrapped in >>>>>>> a >>>>>>> failover endpoint. A leaf endpoint should be valid and meaningful >>>>>>> regardless >>>>>>> how it is being used (eg: with failover or without failover). IMO this >>>>>>> should be a configuration element of the failover endpoint. >>>>>>> >>>>>>> >>>>>> I also think this should be a configuration at the Fail-over endpoint >>>>>> level. >>>>>> >>>>> >>>>> This configuration is per endpoint basis. User should be able to >>>>> configure each and every leaf endpoint according to his requirement. >>>>> >>>> >>>> I don't think there will ever be a case where we have to specify such >>>> failover requirements at leaf endpoint level. Usually all the child >>>> endpoints of a failover endpoint are similar to each other and have similar >>>> configurations. Therefore we can enforce this new configuration element at >>>> the failover endpoint level so that all child endpoints are equally >>>> affected >>>> by it. >>>> >>>> On the other hand, if it is required to support the fine level of >>>> granularity you are thinking of (which is highly unlikely) I believe we >>>> can >>>> still come up with a configuration to support that even with the existing >>>> endpoint configuration model. Failover endpoint will not fall back to a >>>> different child endpoint unless the first endpoint goes into the suspended >>>> state. And we can configure that behavior at leaf endpoint level by using >>>> the markForSuspension configuration element. Your proposal takes this >>>> approach further by making it easier to configure the ESB and also adding >>>> the capability to send faults from a failover endpoint. But I think it >>>> should be done at the failover endpoint level. >>>> >>>> Also IMO doing this at leaf endpoint level, in a way, breaks the overall >>>> endpoint model. Why should a leaf endpoint be aware of failover >>>> requirements >>>> at all? That's a job for the failover endpoint. WDYT? >>>> >>>> Thanks, >>>> Hiranya >>>> >>>> >>>> >>>>> Rajika >>>>> >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Supun.. >>>>>> >>>>>> Thanks, >>>>>>> Hiranya >>>>>>> >>>>>>> >>>>>>>> The new configuration element will go same level as timeOut, >>>>>>>> markForSuspension elements. >>>>>>>> >>>>>>>> <failedMessage> >>>>>>>> <errorCodes>comma separated list of error codes</errorCode> >>>>>>>> <action> discard | fault </action> >>>>>>>> </failedMessage> >>>>>>>> >>>>>>>> erroCodes - Upon receiving this erroCodes the action will be >>>>>>>> performed. Possible values can be same as errorCodes in >>>>>>>> markForSuspension >>>>>>>> or suspendOnFailure. >>>>>>>> action - The action to perform upon receving one of the errorCodes >>>>>>>> from the endpoint. May be we can drop the message or send a fault back. >>>>>>>> >>>>>>>> Your comments are welcome. >>>>>>>> >>>>>>>> Rajika >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Hiranya Jayathilaka >>>>>>> Software Engineer; >>>>>>> >>>>>>> WSO2 Inc.; http://wso2.org >>>>>>> E-mail: [email protected]; Mobile: +94 77 633 3491 >>>>>>> Blog: http://techfeast-hiranya.blogspot.com >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Software Engineer, WSO2 Inc >>>>>> http://wso2.org >>>>>> supunk.blogspot.com >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Hiranya Jayathilaka >>>> Software Engineer; >>>> WSO2 Inc.; http://wso2.org >>>> E-mail: [email protected]; Mobile: +94 77 633 3491 >>>> Blog: http://techfeast-hiranya.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 >>> >> >> >> >> -- >> Hiranya Jayathilaka >> Software Engineer; >> WSO2 Inc.; http://wso2.org >> E-mail: [email protected]; Mobile: +94 77 633 3491 >> Blog: http://techfeast-hiranya.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 > -- Hiranya Jayathilaka Software Engineer; WSO2 Inc.; http://wso2.org E-mail: [email protected]; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
