On 07/21/2011 07:27 PM, Jakub Scholz wrote:
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 qpidd
has loaded its store. Worse, with cluster-size=N, brokers starting up will
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. On the other hand I take your point
that it gives a false impression of readiness. Maybe this behaviour should
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.
Hah! I just remembered: the status is already visible via qpid-config.
[aconway@mrg32 ~]$ qpid-cluster mrg33
Cluster Name: aconway-test-cluster
Cluster Status: ACTIVE
Cluster Size: 4
Members: ID=20.0.100.33:20964
URL=amqp:tcp:20.0.10.33:5672,tcp:10.16.44.238:5672,tcp:20.0.100.33:5672,tcp:192.168.122.1:5672
: ID=20.0.100.34:22472
URL=amqp:tcp:20.0.10.34:5672,tcp:10.16.44.239:5672,tcp:20.0.100.34:5672,tcp:192.168.122.1:5672
: ID=20.0.100.35:31598
URL=amqp:tcp:20.0.10.35:5672,tcp:20.0.20.35:5672,tcp:10.16.44.240:5672,tcp:20.0.100.35:5672,tcp:192.168.122.1:5672
: ID=20.0.100.36:16241
URL=amqp:tcp:10.16.44.241:5672,tcp:20.0.100.36:5672,tcp:20.0.10.36:5672,tcp:20.0.20.36:5672,tcp:192.168.122.1:5672
If the cluster is receiving its initial update the status would be JOINING.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
