Return-Path: X-Original-To: apmail-activemq-users-archive@www.apache.org Delivered-To: apmail-activemq-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C85509490 for ; Thu, 29 Sep 2011 09:41:48 +0000 (UTC) Received: (qmail 75778 invoked by uid 500); 29 Sep 2011 09:41:48 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 75748 invoked by uid 500); 29 Sep 2011 09:41:48 -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 75740 invoked by uid 99); 29 Sep 2011 09:41:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Sep 2011 09:41:48 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sslavic@gmail.com designates 74.125.82.45 as permitted sender) Received: from [74.125.82.45] (HELO mail-ww0-f45.google.com) (74.125.82.45) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Sep 2011 09:41:43 +0000 Received: by wwi36 with SMTP id 36so557373wwi.14 for ; Thu, 29 Sep 2011 02:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=WxOSxLyQNxDDkfUJ0XPXuAI7Eae3KV4kQJO6jHnM3xI=; b=dps+G2lAl6f5YaHaKy1lR+KKEcensXcEzeheMX4MEx4zkeUA7PS7jORYY73ZUOr5ft YxmwOKT3h9rH9APk9HSaKbLg3KtLZOjz93Fv7J1aqOMC9juY2gVfcXVCyVe+5K6isWB/ vkze7d+f3vsjrp/RrhQVpvYJPtrjbYHtUr3dg= MIME-Version: 1.0 Received: by 10.227.179.76 with SMTP id bp12mr3500648wbb.82.1317289282484; Thu, 29 Sep 2011 02:41:22 -0700 (PDT) Received: by 10.180.99.164 with HTTP; Thu, 29 Sep 2011 02:41:22 -0700 (PDT) In-Reply-To: <6264A399-24E8-4D94-8B16-BD4C5F8609B9@fusesource.com> References: <6264A399-24E8-4D94-8B16-BD4C5F8609B9@fusesource.com> Date: Thu, 29 Sep 2011 11:41:22 +0200 Message-ID: Subject: Re: Local shared filesystem master slave with geo-redundant pure master slave From: =?UTF-8?Q?Stevo_Slavi=C4=87?= To: users@activemq.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Torsten for reply and clarifications! Obviously I didn't understand well the difference between master/slave and network of brokers. I think performance constraints are not too high, having HA is more important - message received must be consumed if at least one broker & consumer is running. Will check requirements and get back. Regards, Stevo. On Thu, Sep 29, 2011 at 9:26 AM, Torsten Mielke wr= ote: >> Can failover protocol be used for network connectors? > > Yes, please see http://tmielke.blogspot.com/2011/09/activemq-network-brid= ge-to-masterslave.html > >> Can destinations and >> messages be shared for HA across the geo-redundant nodes? > Using a network connector you do not share messages between brokers but y= ou allow messages to travel between brokers. > I.e. when a msg travels to a different broker it is deleted on the local = broker. Msgs only travel to remote brokers within a network of brokers, whe= n there are consumers registered on the remote broker. > So this will not serve as a master/slave solution. > > Master / Slave is typically done on a shared resource (file system or dat= abase). This will be difficult to setup between brokers on different geo lo= cations. > Pure master slave replicates everything but do you really want this over = a WAN connection? > > Typically users set up master/slave on nodes within one geo location and = connect geo location using a network connector. > > > Torsten Mielke > torsten@fusesource.com > tmielke@blogspot.com > > > On Sep 28, 2011, at 6:17 PM, Stevo Slavi=C4=87 wrote: > >> Hello ActiveMQ users, >> >> Imagine 4 nodes, 2 per location, on each node on same location/LAN a >> shared filesystem (separate node) used by two local brokers in shared >> filesystem master slave (SFSMS) configuration. Can destinations and >> messages be shared for HA across the geo-redundant nodes? >> >> Can failover protocol be used for network connectors? Then AMQ brokers >> on one location could connect to brokers on other location via >> failover protocol. Compared to transport connector failover handling, >> if AMQ brokers from one location can not connect to neither of >> failover AMQ brokers on other location (e.g. if other location is down >> completely, neither of the SFSMS nodes are responding), they should >> continue to operate as if nothing happened (slave not responding, >> down). When other location is brought back up, before putting it >> online one will have to sync the message storage manually, just like >> in pure master slave. For each location, other location would be a >> slave, in a pure master slave configuration. >> >> Does this make sense? Is it feasible with AMQ 5.5.0? >> >> Regards, >> Stevo. > > > > > >