From activemq-users-return-1926-apmail-geronimo-activemq-users-archive=geronimo.apache.org@geronimo.apache.org Mon Jun 12 15:47:02 2006 Return-Path: Delivered-To: apmail-geronimo-activemq-users-archive@www.apache.org Received: (qmail 80811 invoked from network); 12 Jun 2006 15:47:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Jun 2006 15:47:02 -0000 Received: (qmail 41173 invoked by uid 500); 12 Jun 2006 15:47:01 -0000 Delivered-To: apmail-geronimo-activemq-users-archive@geronimo.apache.org Received: (qmail 41148 invoked by uid 500); 12 Jun 2006 15:47:01 -0000 Mailing-List: contact activemq-users-help@geronimo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: activemq-users@geronimo.apache.org Delivered-To: mailing list activemq-users@geronimo.apache.org Received: (qmail 41139 invoked by uid 99); 12 Jun 2006 15:47:01 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Jun 2006 08:47:01 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [208.176.63.109] (HELO localhost.ldsys.net) (208.176.63.109) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Jun 2006 08:46:59 -0700 Received: from [10.0.2.1] (adsl-71-143-209-211.dsl.chcgil.sbcglobal.net [71.143.209.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by localhost.ldsys.net (Postfix) with ESMTP id E93E04690B for ; Mon, 12 Jun 2006 10:51:25 -0500 (CDT) Message-ID: <448D8C56.3060008@ldsys.net> Date: Mon, 12 Jun 2006 10:46:30 -0500 From: "Christopher G. Stach II" User-Agent: Thunderbird 1.5.0.4 (X11/20060603) MIME-Version: 1.0 To: activemq-users@geronimo.apache.org Subject: Redelivery delay backoff factor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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