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