On 6/12/06, Christopher G. Stach II <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/
