Re: Extending the endpoint configuration to handle the message in error situations (timeout, connection refused etc..) in a failover scenario

[Hiranya Jayathilaka <hi...@gmail.com>]

On Mon, Feb 1, 2010 at 12:44 AM, Ruwan Linton <ru...@gmail.com>wrote:

>
>
> On Sun, Jan 31, 2010 at 7:58 PM, Hiranya Jayathilaka <hiranya911@gmail.com
> > wrote:
>
>>
>>
>> On Sun, Jan 31, 2010 at 6:07 PM, Ruwan Linton <ru...@gmail.com>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.
>

+1


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

As long as this configuration offers some functionality for individual leaf
endpoints it is fine to configure at that level.

Thanks,
Hiranya


> Thanks,
> Ruwan
>
>>
>> Thanks,
>> Hiranya
>>
>>
>>> Thanks,
>>> Ruwan
>>>
>>>
>>> On Sun, Jan 31, 2010 at 4:28 PM, Hiranya Jayathilaka <
>>> hiranya911@gmail.com> wrote:
>>>
>>>> Hi Rajika,
>>>>
>>>> Please see my comments inline.
>>>>
>>>> On Sun, Jan 31, 2010 at 3:37 PM, Rajika Kumarasiri <ra...@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 <ra...@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
>>>>
>>>
>>>
>>>
>>> --
>>> Ruwan Linton
>>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>>> WSO2 Inc.; http://wso2.org
>>> email: ruwan@wso2.com; cell: +94 77 341 3097
>>> blog: http://ruwansblog.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
>>
>
>
>
> --
> Ruwan Linton
> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> WSO2 Inc.; http://wso2.org
> email: ruwan@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.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