synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiranya Jayathilaka <hiranya...@gmail.com>
Subject Re: [Dead Letter channel EIP] Question on redelivery mechanism
Date Sun, 13 Jun 2010 16:24:06 GMT
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,
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

Mime
View raw message