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
