synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiranya Jayathilaka <hiranya...@gmail.com>
Subject Re: Extending the endpoint configuration to handle the message in error situations (timeout, connection refused etc..) in a failover scenario
Date Sun, 31 Jan 2010 10:58:59 GMT
Hi Rajika,

Please see my comments inline.

On Sun, Jan 31, 2010 at 3:37 PM, Rajika Kumarasiri <rajika@wso2.com> wrote:

>
>
> On Sun, Jan 31, 2010 at 12:27 PM, Supun Kamburugamuva <supun06@gmail.com>wrote:
>
>>
>>
>> On Sun, Jan 31, 2010 at 11:10 AM, Hiranya Jayathilaka <
>> hiranya911@gmail.com> wrote:
>>
>>> Hi Rajika,
>>>
>>> On Sun, Jan 31, 2010 at 9:31 AM, Rajika Kumarasiri <rajika@wso2.com>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: hiranya@wso2.com;  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: hiranya@wso2.com;  Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com

Mime
View raw message