You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by "Christopher G. Stach II" <cg...@ldsys.net> on 2006/06/12 17:46:30 UTC
Redelivery delay backoff factor
If a rollback on two messages happens between three transactional
deliveries, and the two messages are redelivered with the same
redelivery backoff settings, there is a likelihood that both messages
will cause another rollback to happen. If maximumRedeliveries is set
too low, or there are a maximumRedeliveries + 1 messages coming in
simultaneously, messages may never get delivered. Can we get another
option for the clients that adds a random backoff delay adjustment in
addition to the constant backoff delay factor? This would end up
working like most other collision avoidance algorithms.
--
Christopher G. Stach II
Re: Redelivery delay backoff factor
Posted by James Strachan <ja...@gmail.com>.
On 6/12/06, Christopher G. Stach II <cg...@ldsys.net> wrote:
> James Strachan wrote:
> > Sure - wanna raise a JIRA for this? (A patch would be even better :)
> >
> > On 6/12/06, Christopher G. Stach II <cg...@ldsys.net> wrote:
> >> If a rollback on two messages happens between three transactional
> >> deliveries, and the two messages are redelivered with the same
> >> redelivery backoff settings, there is a likelihood that both messages
> >> will cause another rollback to happen. If maximumRedeliveries is set
> >> too low, or there are a maximumRedeliveries + 1 messages coming in
> >> simultaneously, messages may never get delivered. Can we get another
> >> option for the clients that adds a random backoff delay adjustment in
> >> addition to the constant backoff delay factor? This would end up
> >> working like most other collision avoidance algorithms.
>
> I will see if I can dedicate some time to it this week. It would really
> help out over here.
Great stuff!
Just a quick heads up; there are 2 points in the code that redelivery
takes place, depending on if you are using the ConnectionConsumer /
ResourceAdapter / Application Server or straight JMS client code.
The former is in ActiveMQSession.run() the latter in
ActiveMQMessageConsumer.rollback().
It might be we could refactor the code a little for calculating the
redelivery timeouts (maybe pushing more of the calculation logic back
into the RedeliveryPolicy itself.
--
James
-------
http://radio.weblogs.com/0112098/
Re: Redelivery delay backoff factor
Posted by "Christopher G. Stach II" <cg...@ldsys.net>.
James Strachan wrote:
> Sure - wanna raise a JIRA for this? (A patch would be even better :)
>
> On 6/12/06, Christopher G. Stach II <cg...@ldsys.net> wrote:
>> If a rollback on two messages happens between three transactional
>> deliveries, and the two messages are redelivered with the same
>> redelivery backoff settings, there is a likelihood that both messages
>> will cause another rollback to happen. If maximumRedeliveries is set
>> too low, or there are a maximumRedeliveries + 1 messages coming in
>> simultaneously, messages may never get delivered. Can we get another
>> option for the clients that adds a random backoff delay adjustment in
>> addition to the constant backoff delay factor? This would end up
>> working like most other collision avoidance algorithms.
I will see if I can dedicate some time to it this week. It would really
help out over here.
--
Christopher G. Stach II
Re: Redelivery delay backoff factor
Posted by James Strachan <ja...@gmail.com>.
Sure - wanna raise a JIRA for this? (A patch would be even better :)
On 6/12/06, Christopher G. Stach II <cg...@ldsys.net> wrote:
> If a rollback on two messages happens between three transactional
> deliveries, and the two messages are redelivered with the same
> redelivery backoff settings, there is a likelihood that both messages
> will cause another rollback to happen. If maximumRedeliveries is set
> too low, or there are a maximumRedeliveries + 1 messages coming in
> simultaneously, messages may never get delivered. Can we get another
> option for the clients that adds a random backoff delay adjustment in
> addition to the constant backoff delay factor? This would end up
> working like most other collision avoidance algorithms.
>
> --
> Christopher G. Stach II
>
--
James
-------
http://radio.weblogs.com/0112098/