Return-Path: Delivered-To: apmail-geronimo-activemq-users-archive@www.apache.org Received: (qmail 74625 invoked from network); 4 Apr 2006 08:50:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Apr 2006 08:50:55 -0000 Received: (qmail 46126 invoked by uid 500); 4 Apr 2006 08:50:55 -0000 Delivered-To: apmail-geronimo-activemq-users-archive@geronimo.apache.org Received: (qmail 46005 invoked by uid 500); 4 Apr 2006 08:50:54 -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 45996 invoked by uid 99); 4 Apr 2006 08:50:54 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Apr 2006 01:50:54 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of james.strachan@gmail.com designates 66.249.92.205 as permitted sender) Received: from [66.249.92.205] (HELO uproxy.gmail.com) (66.249.92.205) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Apr 2006 01:50:53 -0700 Received: by uproxy.gmail.com with SMTP id m3so848601ugc for ; Tue, 04 Apr 2006 01:50:32 -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=UmTVLrfmZul63D6btaAVIqJEMyR2gUEhk6wu5hIrESZIYydbr4NLpz8z0uPNt6VKHYDWNDIYjjFAjrOAhbHEkHkNCDd9B/ah5pKiy7PxVFy5xdJySFIPx8a7Um80HqVI6j8TW+IQzKHCFI9H8Clvp8VaaB/u1gj//B4iYzBc+Cg= Received: by 10.78.31.18 with SMTP id e18mr159395hue; Tue, 04 Apr 2006 01:50:32 -0700 (PDT) Received: by 10.78.27.13 with HTTP; Tue, 4 Apr 2006 01:50:32 -0700 (PDT) Message-ID: Date: Tue, 4 Apr 2006 09:50:32 +0100 From: "James Strachan" To: activemq-users@geronimo.apache.org Subject: Re: Topology for resilience and failover In-Reply-To: <3E7FE7F1841E3441A566885FEDDCDECE43C151@SPR3V2.office.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <3E7FE7F1841E3441A566885FEDDCDECE43C151@SPR3V2.office.local> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 4/4/06, Meeraj Kunnumpurath wrote: > Hi, > > We are planning to use ActiveMQ standalone (for transactional and > persistent messaging) with the JMS clients running on a cluster of > Weblogic servers. We are using the ACtiveMQ JCA adaptor to enlist JMS > access within the WLS transaction manager. I would highly appreciate it, > if someone could please answer the following questions. > > 1. What is the best configuration for clustering ActiveMQ to provide > throughput and failover. For maximum throughput, if you can avoid XA then go for it... http://activemq.org/Should+I+use+XA Other than that - make sure you use the high performance journal with ActiveMQ (which is enabled by default). You can increase throughput of XA using batching; to batch messages together into a single XA transaction - which shares the cost of the XA protocol across many messages. Though be a little careful that your other XA resources can handle it - such as your database with locking etc. http://activemq.org/Activation+Spec+Properties For failover; there are 2 things to consider. Client side failover (when a broker fails to make the client reconnect and resume any in-flight messages etc). Thats pretty simple and lightweight using the failover: transport on the client. By default if you are using either separate brokers or brokers networked together in a demand-forwarding network; a message exists on one broker at any point in time until its consumed by a client. So if a broker goes down; it needs to be restarted (from the persistent disk files) to be able to recover messages and send them on their way. If you want to deal with catastrophic hardware failure (loosing disks) - assuming you have no SAN/RAID hardware - then we have a Master/Slave configuration which ensures that every message is replicated onto a slave broker so there are 2 physical copies at any point in time - then the master can failover to the slave. http://activemq.org/MasterSlave But this does affect throughput. So its all a balancing act between throughput, latency, reliability and risk etc > 2. Which of the ActiveMQ persistent files (journals, tlogs etc) need to > be stored on fault-tolerant hardware to enable XA recovery from > catastrophic failures like disk crashes? All of them :) So the ActiveMQ journal, its long term persistent JDBC store (such as the default Derby files or some other DB if you prefer). Also your WLS transaction manager log as well. -- James ------- http://radio.weblogs.com/0112098/