From users-return-9019-apmail-activemq-users-archive=activemq.apache.org@activemq.apache.org Wed May 09 02:30:49 2007
Return-Path:
Delivered-To: apmail-activemq-users-archive@www.apache.org
Received: (qmail 83241 invoked from network); 9 May 2007 02:30:47 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 9 May 2007 02:30:47 -0000
Received: (qmail 14668 invoked by uid 500); 9 May 2007 02:30:52 -0000
Delivered-To: apmail-activemq-users-archive@activemq.apache.org
Received: (qmail 14654 invoked by uid 500); 9 May 2007 02:30:52 -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 14644 invoked by uid 99); 9 May 2007 02:30:52 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 May 2007 19:30:52 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of dbudworth@gmail.com designates 209.85.132.244 as permitted sender)
Received: from [209.85.132.244] (HELO an-out-0708.google.com) (209.85.132.244)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 May 2007 19:30:45 -0700
Received: by an-out-0708.google.com with SMTP id d40so8839and
for ; Tue, 08 May 2007 19:30:24 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
d=gmail.com; s=beta;
h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
b=Wog4DMwEuR4McK4wFa0SF3iOO90d7MT1TIhGw0lMWTzYS4HEP3fY3Urzx5rBYU4KP5f8dS+iFgko56Dv7/s60mVZgvR7yR4qGjQS09V919CzMwTA8muUl5ZjCtZqia6xAKtJ91Hgtwr4WNGN8VsSR5nv7H/6nzMZ6NLal3p32qc=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=beta;
h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
b=q0qJNYlWlg63GTsZW0vvBYaWerGXdyubqFbBTc5tCtyIXLLbARUxs+Vn/xmEIqPh2xJVLAbVC5Elcx8i6XBGDbdeC0emmthq2+EjXps8G297reYRKwk5zTIsGBSEg4MMkLqFpCT7mmx0MtxU9E4CbDxwHmxQ9I8lX//m3jMM0C4=
Received: by 10.100.121.12 with SMTP id t12mr13970anc.1178677824448;
Tue, 08 May 2007 19:30:24 -0700 (PDT)
Received: by 10.100.48.6 with HTTP; Tue, 8 May 2007 19:30:24 -0700 (PDT)
Message-ID: <2e23d1d20705081930v11714a5cj3c736b69e298c014@mail.gmail.com>
Date: Tue, 8 May 2007 21:30:24 -0500
From: "David Budworth"
To: users@activemq.apache.org
Subject: Re: question about Master/Slave shared-nothing and synchronization
In-Reply-To: <2e23d1d20705041238r99578feo8d5664f6b39954f5@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_128808_18218857.1178677824314"
References: <2e23d1d20705040748g33f1a44bwb58fab7fc895d17c@mail.gmail.com>
<2e23d1d20705041238r99578feo8d5664f6b39954f5@mail.gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org
------=_Part_128808_18218857.1178677824314
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
slight followup to my own question here,
assuming we had a pure master/slave setup and the master dies, we then:
1) stop slave
2) copy files from slave to master
3) delete files from slave?
4) start master
5) (since clients were sitting the retrying, they'll connect and start
sending before slave can be started)
6) start slave
If I understand correctly, since there is no existing state synchronization
that any messages posted to the master's queues at step #5 would be unknown
by the slave and thus 'lost' if the master were to fail again.
Also, if I didn't do step #3, and left the data files as is on the slave and
then at #5 the clients start sending before the slave starts up, we'll have
the issue of lost acks and possible duplicate deliveries in the event of a
failover?
And one more thing, I saw that the slave doesn't allow connections. But the
socket is open and responds when you connect in to it. And I see no way
from JMX to check to see if the slave is acting 'master'.
My concern here is that it appears that the only way to tell if the slave is
acting master is to possibly try to send a test message directly to the
slave and see if it throws? (didn't try it, but I'd guess it would) Or
maybe the connect would through (can't tell just by telnetting into a
server).
On the issue of startup state synchronization, I don't suppose there's a
means (internal api wise) to block all client connections in AMQ? If we go
the AMQ route for our stuff, we may be able to implement the Master/Slave
synchronization piece ourselves and contribute it back, assuming it doesn't
involve some kind of fundamental change to the system. Possibly a
synchronizing hook above the persistence mechanism that would just block
persistence writes while state sync occurs. Would require the master to
know about the slave though so it can sync back (or be master/slave in the
longest-up-is-master way)
Thanks,
-David
On 5/4/07, David Budworth wrote:
>
> true, but I was shooting for zero message loss and reasonably high
> performance with no single points of failure
>
> shared db will put us right back at single point of failure(db) that we're
> looking to avoid with MasterSlave
>
> On 5/4/07, Hiram Chirino wrote:
> >
> > If you use a shared DB or file system you should be able to failover
> > and fail back without a problem.
> >
> > On 5/4/07, David Budworth wrote:
> > > I mistakenly hijacked another thread yesterday when asking this, so
> > I'll
> > > repost it as it's own thread.
> > >
> > > If I understand the wiki and comments I've read on this list recently,
> > AMQ
> > > has no state synchronizer.
> > >
> > > Meaning that if I have Master / Slave and the Master dies, i can't
> > restart
> > > it without stopping the slave, copying it's database over to the
> > master then
> > > restarting both.
> > >
> > > The part I'm confused about is how does work when you have clients
> > > attempting to send messages?
> > >
> > > If I start up the master and clients reconnect and start sending
> > messages,
> > > then start the slave, what happens?
> > >
> > > Do I need the clients to wait until both master and slave are both up
> > before
> > > it starts sending?
> > >
> > > Or does Master -> Slave state sync work fine, it's just that you can't
> > do it
> > > the other way?
> > >
> > > Reason I'm asking is that we currently use SonicMQ for their CAA
> > feature
> > > which allows transparent failover / failback which is great.
> > >
> > > We would like to use AMQ for some things that have special
> > requirements we
> > > don't get from SMQ but at the same time we don't want to give up the
> > HA
> > > aspects of having the clients not have to be stopped/started in the
> > event we
> > > have a broker failure and want to eventually get back to normal
> > Master/Slave
> > > environment.
> > >
> > > Thanks,
> > > -David
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
>
>
------=_Part_128808_18218857.1178677824314--