Return-Path: Delivered-To: apmail-geronimo-activemq-users-archive@www.apache.org Received: (qmail 34846 invoked from network); 3 Aug 2006 14:42:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 3 Aug 2006 14:42:48 -0000 Received: (qmail 46386 invoked by uid 500); 3 Aug 2006 14:42:47 -0000 Delivered-To: apmail-geronimo-activemq-users-archive@geronimo.apache.org Received: (qmail 46370 invoked by uid 500); 3 Aug 2006 14:42:47 -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 46361 invoked by uid 99); 3 Aug 2006 14:42:47 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Aug 2006 07:42:47 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of james.strachan@gmail.com designates 66.249.82.195 as permitted sender) Received: from [66.249.82.195] (HELO wx-out-0102.google.com) (66.249.82.195) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Aug 2006 07:42:45 -0700 Received: by wx-out-0102.google.com with SMTP id i27so210040wxd for ; Thu, 03 Aug 2006 07:42:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jQjqJ9RunfBjHuLOc4LyNQAm4EbYDjp03t1UmeZMD38CcnUABvlVnrA1066w0knlGPjarl4pP6jlVwAeqq3vdVAbCAcchzdzCRuZxMfe0NFEFGkCg9qQ3ycyk3SIns3hpojYNm95svIPh+A65TwbC0PgKvDYQI+kP0o6iRL0eiA= Received: by 10.78.123.4 with SMTP id v4mr746002huc; Thu, 03 Aug 2006 07:42:24 -0700 (PDT) Received: by 10.78.174.8 with HTTP; Thu, 3 Aug 2006 07:42:24 -0700 (PDT) Message-ID: Date: Thu, 3 Aug 2006 15:42:24 +0100 From: "James Strachan" To: activemq-users@geronimo.apache.org Subject: Re: Question about clustering and reliable delivery In-Reply-To: <5632611.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5632611.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 8/3/06, Abdul Alhazred wrote: > > OK, here's the scenario: > > I have a number of producers, which produce a rather large number of > messages, thus I need to be able to direct these messages to a set of > clustered ActiveMQ brokers, and likewise there are numbers of consumers on > the other side of the cluster receiving these messages. > > So far this is all fine, but these messages MUST be guaranteed delivered and > processed in order. Exclusive Consumer is fine for this. Now what happens if > the database server backing one of the brokers in the cluster fails? Both > the consumers and producers can fail over to another broker, but now > whatever messages are stored in that particular database are GONE (IE any > which haven't yet been consumed). The assumption is that the file or database is reliable. Failing that you can use Master/Slave to replicate to different disks. http://incubator.apache.org/activemq/masterslave.html > What would be a recommended solution? It looks like ActiveMQ 4.1's JDBC > master/slave would be a good answer, but I'd really like to have a solution > I can deploy in the near term. JDBC master/slave works great today - assuming you have reilable databases. Though its fairly slow since it requires you to disable the high performance journal. Using a shared file system Master/Slave or using straight Master/Slave is probably your best option if you have high performance requirements > Pure database replication doesn't appear to > be a real answer because master/slave replication in RDBMS are asynchronous > (thus the slave database server might not yet have received all updates at > the point where the crash occured). Besides in that case it would seem a new > broker would have to join the cluster and start up using the replica > database, which brings up various issues with what would happen with > ordering of message delivery in the mean time. Ordering is guarrenteed with Shared-FileSystem and JDBC based Master/Slaves. -- James ------- http://radio.weblogs.com/0112098/