From users-return-14440-apmail-activemq-users-archive=activemq.apache.org@activemq.apache.org Fri Jun 06 13:53:55 2008 Return-Path: Delivered-To: apmail-activemq-users-archive@www.apache.org Received: (qmail 16547 invoked from network); 6 Jun 2008 13:53:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Jun 2008 13:53:54 -0000 Received: (qmail 97707 invoked by uid 500); 6 Jun 2008 13:53:56 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 97692 invoked by uid 500); 6 Jun 2008 13:53:56 -0000 Mailing-List: contact users-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@activemq.apache.org Delivered-To: mailing list users@activemq.apache.org Received: (qmail 97681 invoked by uid 99); 6 Jun 2008 13:53:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Jun 2008 06:53:56 -0700 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rajdavies@gmail.com designates 209.85.128.184 as permitted sender) Received: from [209.85.128.184] (HELO fk-out-0910.google.com) (209.85.128.184) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Jun 2008 13:53:05 +0000 Received: by fk-out-0910.google.com with SMTP id z22so817026fkz.6 for ; Fri, 06 Jun 2008 06:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=vG7rJdsRj4WaZWuA37FLD3G9efFxl5zhlZUCPZ+aCXg=; b=Bz2sPZiYXqcXogcwIn3MpB7INooe6htZaN1gB6VXxZk9N1evqJxIDO5E/FnJ5Ah0H+ fAmr9XvIQzn/oi2/EF/pfYzmPsuauXASmRrgPpT2EprWgIbLgMOrp7Czd6htRS1hS8p6 LktxSOrBGfhI/7pqQJVfGzjdW1wmoX8ug6ByI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=rI0tN8Ww/ZQSipO6MjANFdDKrZ7L7YSAf24x1G4u6S9PNg0cCO4j3XlUEWMDPU+AfY zWPYAGkErvBrW6FRK6t9cf2/7WtChkFmb9pt6Lus19GCjBmkNkkFdmFp7SR3WSO41fiA xAS6H33FZDOIMuXjViWgyDf6Ix3sbTkg4Rdjg= Received: by 10.210.66.1 with SMTP id o1mr48337eba.135.1212760401491; Fri, 06 Jun 2008 06:53:21 -0700 (PDT) Received: from ?192.168.1.75? ( [86.133.81.234]) by mx.google.com with ESMTPS id q9sm8050689gve.5.2008.06.06.06.53.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Jun 2008 06:53:20 -0700 (PDT) Message-Id: <76D502C3-E184-4E02-B607-91227A178A15@gmail.com> From: Rob Davies To: users@activemq.apache.org In-Reply-To: <17691674.post@talk.nabble.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: Redelivery sticks to and blocks a consumer thread Date: Fri, 6 Jun 2008 14:53:18 +0100 References: <13261850.post@talk.nabble.com> <17691674.post@talk.nabble.com> X-Mailer: Apple Mail (2.924) X-Virus-Checked: Checked by ClamAV on apache.org I'd certainly try 5.1 cheers, Rob On 6 Jun 2008, at 14:05, Demian Mrakovich wrote: > > Hi, bumping this one... Has this (I'd have to say major) issue been > addressed > in newer versions of ActiveMQ? > > > Jason Rosenberg wrote: >> >> All, >> >> I have been experimenting with using exponentialBackOff as a >> redelivery >> policy. I have multiple parallel consumers. I'm using AMQ 4.1.1, >> using >> Spring's DefaultMessageListener, within Tomcat 6. >> >> I've noticed that when a message consumer has a failure, and throws >> an >> exception, and the message gets scheduled for retry, the particular >> consumer thread gets tied to the redelivery, and it doesn't process >> any >> more messages until it's gone through the full redelivery schedule >> for the >> error prone message. So, with the exponentialBackOff mode, it's >> easy to >> set it to wait 10 minutes before redelivering a failed message, and >> in >> that time that consumer will be blocked. >> >> If the consumer has a pre-fetch greater than 1, this means other >> messages >> which might be perfectly valid for processing are blocked until the >> troubled message goes through it's full redelivery cycle (which >> could be >> infinite!).... >> >> I'm wondering if there's an alternate way to configure things, so >> that a >> message marked for redelivery goes back on the queue to be >> scheduled by >> the next available consumer (and not until it's next scheduled >> redelivery >> time has arrived!).... >> >> If I have a queue with multiple consumers, and perhaps even a small >> percentage of the messages are corrupt and force multiple retries, it >> could eventually happen that all consumers are blocked waiting idly >> to >> retry the message at the top of it's list, even though other >> messages are >> readily available. This would seem to be the case even when the >> prefetch >> limit is 1. >> >> Thoughts? >> >> Jason >> > > -- > View this message in context: http://www.nabble.com/Redelivery-sticks-to-and-blocks-a-consumer-thread-tp13261850s2354p17691674.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >