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. 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. 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
