You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Charith Wickramarachchi <ch...@gmail.com> on 2010/06/13 08:01:54 UTC
[Dead Letter channel EIP] Question on redelivery mechanism
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 ?
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/
Re: [Dead Letter channel EIP] Question on redelivery mechanism
Posted by Charith Wickramarachchi <ch...@gmail.com>.
On Sun, Jun 13, 2010 at 9:54 PM, Hiranya Jayathilaka
<hi...@gmail.com>wrote:
>
>
> On Sun, Jun 13, 2010 at 6:40 PM, Ruwan Linton <ru...@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/
Re: [Dead Letter channel EIP] Question on redelivery mechanism
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
On Sun, Jun 13, 2010 at 6:40 PM, Ruwan Linton <ru...@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
Re: [Dead Letter channel EIP] Question on redelivery mechanism
Posted by Ruwan Linton <ru...@gmail.com>.
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.
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