Mailing-List: contact activemq-users-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-users@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <448D8FEA.7020007@ldsys.net>
Date: Mon, 12 Jun 2006 11:01:46 -0500
From: "Christopher G. Stach II" <cgs@ldsys.net>
User-Agent: Thunderbird 1.5.0.4 (X11/20060603)
MIME-Version: 1.0
To: activemq-users@geronimo.apache.org
Subject: Re: Redelivery delay backoff factor
References: <448D8C56.3060008@ldsys.net>
 <ec6e67fd0606120848s3002c4cdm5cbdaa752aa97104@mail.gmail.com>
In-Reply-To: <ec6e67fd0606120848s3002c4cdm5cbdaa752aa97104@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

James Strachan wrote:
> Sure - wanna raise a JIRA for this? (A patch would be even better :)
> 
> On 6/12/06, Christopher G. Stach II <cgs@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