Return-Path: Delivered-To: apmail-activemq-users-archive@www.apache.org Received: (qmail 11254 invoked from network); 22 Apr 2010 10:04:00 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 22 Apr 2010 10:04:00 -0000 Received: (qmail 29726 invoked by uid 500); 22 Apr 2010 10:04:00 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 29571 invoked by uid 500); 22 Apr 2010 10:03:58 -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 29562 invoked by uid 99); 22 Apr 2010 10:03:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Apr 2010 10:03:57 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=FORGED_HOTMAIL_RCVD2,FREEMAIL_FROM,SPF_HELO_PASS,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Apr 2010 10:03:52 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1O4tFr-0001Uy-PE for users@activemq.apache.org; Thu, 22 Apr 2010 03:03:31 -0700 Message-ID: <28326754.post@talk.nabble.com> Date: Thu, 22 Apr 2010 03:03:31 -0700 (PDT) From: TonyTobin To: users@activemq.apache.org Subject: Re: Understanding the Exclusive Consumer In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: cavanaghtony@hotmail.com References: <28288049.post@talk.nabble.com> <28325468.post@talk.nabble.com> <28326125.post@talk.nabble.com> Thanks Gary You have been a great help Gary Tully wrote: > > There are no real options there, it is handled by the broker and it > simply replays any unacked messages to the next consumer. > For the consumer app, there is the possibility that the second consumer > can > get a duplicate if there is an outstanding ack at the time of failover, so > the consumers needs to be able to deal with this. Even with transactions, > with an outstanding commit reply, the consumer cannot know if the ack was > delivered so the message may or may not get redelivered. XA 2PC is the > only > way to avoid the duplicate problem if the consumers need > to guarantee persistence. Taking an optimistic approach and dealing with > duplicates when they occur by remembering the message id in the store data > is the other option. > > Not sure of other links that deal with this, but the info above may give > you > key words that can help in your research. > > > On 22 April 2010 10:13, TonyTobin wrote: > >> >> Thanks Gary, >> >> That makes sence. >> >> >> Are there any decent links on the different strategies for message >> persistence within consumers. >> >> A consumer is building up messages and then falls over, how the other >> consumer takes over. Managing failover within the consumer cluster. >> >> Thank you for your help >> >> Tony >> >> >> Gary Tully wrote: >> > >> > yes, but the consumers all have to be present, they already content for >> > the >> > lock. >> > >> > imagine an app that has a hot standby, both the primary and hot standby >> > have >> > started consumers. The broker delivers messages to the first consumer, >> the >> > primary (because it got there first) and when/if it fails, it will >> deliver >> > messages to the second consumer (the hot standby). So the broker >> chooses >> > but >> > only from among the current active consumers. >> > >> > On 22 April 2010 09:09, TonyTobin wrote: >> > >> >> >> >> Thank you for your reply Gary, >> >> >> >> In the documentation for exclusive Consumer, it states >> >> >> >> "The broker will pick a single MessageConsumer to get all the messages >> >> for >> >> a >> >> queue to ensure ordering. If that consumer fails, the broker will auto >> >> failover and choose another consumer" >> >> >> >> Doesnt this mean that the broker selects the next consumer, rather >> than >> >> the >> >> consumer going for the lock. >> >> >> >> Thanks again for your reply. >> >> >> >> >> >> >> >> Gary Tully wrote: >> >> > >> >> > exclusive consumer is a simple solution to the case where there are >> >> many >> >> > consumers but only one should be active at any time. Rather than >> some >> >> > application logic keeping track of which one should be active, they >> all >> >> > have >> >> > a go and the broker ensures exclusive access. >> >> > >> >> > So each consumer connects but only one of them gets the exclusive >> lock >> >> and >> >> > gets the messages. When it dies, the next consumer in line gets the >> >> > messages. If effectively allows consumers to stack waiting for the >> >> current >> >> > consumer to die. >> >> > >> >> > On 21 April 2010 16:35, TonyTobin wrote: >> >> > >> >> >> >> >> >> In the ActiveMQ doc >> >> http://activemq.apache.org/exclusive-consumer.htmlit >> >> >> states >> >> >> >> >> >> The broker will pick a single MessageConsumer to get all the >> messages >> >> for >> >> >> a >> >> >> queue to ensure ordering. If that consumer fails, the broker will >> auto >> >> >> failover and choose another consumer. >> >> >> >> >> >> Is this a consumer master slave relationship, the broker will send >> all >> >> >> messages to the designated consumer, and the consumer passes the >> >> messages >> >> >> onto the other consumers. Or does the broker send the messages to >> all >> >> the >> >> >> consumers, but only one consumer acknowledges them, so if that >> >> consumer >> >> >> dies the other consumer can then pick up where the first consumer >> >> died. >> >> >> >> >> >> If there is a link that covers Queue consumer clusters in more >> depth, >> >> I >> >> >> would be grateful if you could post it. >> >> >> >> >> >> Thanks Tony >> >> >> >> >> >> Thanks Tony >> >> >> >> >> >> >> >> >> -- >> >> >> View this message in context: >> >> >> >> >> >> http://old.nabble.com/Understanding-the-Exclusive-Consumer-tp28288049p28288049.html >> >> >> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >> >> >> >> >> >> >> >> > >> >> > >> >> > -- >> >> > http://blog.garytully.com >> >> > >> >> > Open Source Integration >> >> > http://fusesource.com >> >> > >> >> > >> >> >> >> -- >> >> View this message in context: >> >> >> http://old.nabble.com/Understanding-the-Exclusive-Consumer-tp28288049p28325468.html >> >> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >> >> >> >> >> > >> > >> > -- >> > http://blog.garytully.com >> > >> > Open Source Integration >> > http://fusesource.com >> > >> > >> >> -- >> View this message in context: >> http://old.nabble.com/Understanding-the-Exclusive-Consumer-tp28288049p28326125.html >> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >> >> > > > -- > http://blog.garytully.com > > Open Source Integration > http://fusesource.com > > -- View this message in context: http://old.nabble.com/Understanding-the-Exclusive-Consumer-tp28288049p28326754.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.