synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charith Wickramarachchi <charith.dhanus...@gmail.com>
Subject Re: [Dead Letter channel EIP] Question on redelivery mechanism
Date Mon, 14 Jun 2010 10:06:37 GMT
On Sun, Jun 13, 2010 at 9:54 PM, Hiranya Jayathilaka
<hiranya911@gmail.com>wrote:

>
>
> On Sun, Jun 13, 2010 at 6:40 PM, Ruwan Linton <ruwan.linton@gmail.com>wrote:
>
>> Hi Charith,
>>
>> On Sun, Jun 13, 2010 at 11:31 AM, Charith Wickramarachchi <
>> charith.dhanushka@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> While Woking on the next patch for the Dead Letter Channel implementation
>>> i got a question about the redelivery mechanism.
>>>
>>> if a message fails it can be re tried to deliver.(according to a policy
>>> stated in configuration ).
>>> Problem is where to store them till it get processed by the Re delivery
>>> processor?
>>>
>>> following are the options
>>>
>>>
>>>    1. Store it in the Message Store and Re delivery processor will poll
>>>    the message store and try to redeliver the messages.
>>>    2. Store it in a Memory associated with the Re delivery processor and
>>>    try to reliever(This is a temp. memory where it only stores re delivery
>>>    pending messages ). and if the re delivery fails it will be stored in the
>>>    Message store.
>>>
>>>
>>> I personally prefer the 2nd approach since it will give a clear cut
>>> separation for Message store and the Re-delivery processor where we can say
>>> Message store is to store failed Messages.
>>>
>>> WDYT ?
>>>
>>
>> From your explanation it seems like the Message Store is used to keep the
>> failed messages, so it is not wrong to put the first time failed messages to
>> that as well, the advantage that you are getting is that, with a persisted
>> Message Store, we could support re-delivery even after a restart.
>>
>
> +1
>
> If a failure occurs while performing a redelivery, the message should go
> back to the message store. It's not a good idea to store messages all over
> the place. This is in-line with most retry mechanisms we encounter in
> applications. For an example take JMS transactions. If a transaction fails,
> the message is put back to the original queue.
>
>
   Thanks for the feed backs. I'll  go with that approach



> Thanks,
> Hiranya
>
>
>> Thanks,
>> Ruwan
>>
>>
>>>
>>> I'll soon be able to provide the next patch which contain View API based
>>> on JMX for Message store and Improvements in the Re-delivery processor.
>>>
>>> And also suggestions for  the View api is also welcome :)
>>>
>>> thanks,
>>> /Charith
>>> --
>>> Charith Dhanushka Wickramarachchi
>>> http://charithwiki.blogspot.com/
>>>
>>>
>>
>>
>> --
>> Ruwan Linton
>> Software Architect & Product Manager, WSO2 ESB; http://wso2.org/esb
>> WSO2 Inc.; http://wso2.org
>>
>> Lean . Enterprise . Middleware
>>
>> phone: +1 408 754 7388 ext 51789
>> email: ruwan@wso2.com; cell: +94 77 341 3097
>> blog: http://blog.ruwan.org
>> linkedin: http://www.linkedin.com/in/ruwanlinton
>> google: http://www.google.com/profiles/ruwan.linton
>> tweet: http://twitter.com/ruwanlinton
>>
>
>
>
> --
> Hiranya Jayathilaka
> Senior Software Engineer;
>
> WSO2 Inc.;  http://wso2.org
> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>



-- 
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/

Mime
View raw message