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