Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4E286D1F.2000709@redhat.com>
References: 
 <CAOhBXQ7Q5_GdOX5TB19xCbLZpruFWkEJMEz=LDO20twAXtB1Sg@mail.gmail.com>
	<4E283551.6060309@redhat.com>
	<CAOhBXQ4dbNh68aZWENn4=8wf1PtrCDOW1GFmBsr=4he8dd00tA@mail.gmail.com>
	<4E286D1F.2000709@redhat.com>
Date: Fri, 22 Jul 2011 01:27:46 +0200
Message-ID: 
 <CAOhBXQ5sJ4BZCBeeWrxW1tsqVSFHHtqQO5YcqBp4k6Za_g6LEw@mail.gmail.com>
Subject: Re: How to detect the initial synchronization of brokers in cluster
From: Jakub Scholz <jakub@scholz.cz>
To: Alan Conway <aconway@redhat.com>
Cc: users@qpid.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> There is a reason for this behaviour. Qpidd is run by service startup
> scripts and I don't want to block other services from starting until qpid=
d
> has loaded its store. Worse, with cluster-size=3DN, brokers starting up w=
ill
> wait till there are N members in the cluster so they can sync their store
> status. If qpidd didn't return till this was done, it could delay startup=
 of
> the host for an arbitrarily long time. =A0On the other hand I take your p=
oint
> that it gives a false impression of readiness. Maybe this behaviour shoul=
d
> be configurable.
>

Well, yes, configuring this in qpidd directly will be certainly nice.
But I guess for most situations it will be completely fine if the
status can be displayed using qpid-cluster, qpid-cluster-store or some
simmilar utility. That may be easier then modifying qpidd directly and
at the end using a bit of shell programming, you can achieve almost
the same effect.

Thanks & Regards
Jakub

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org