Alan Conway wrote:
At the moment a clustered broker stalls clients while it is
initializing, giving or receiving an update. It's been pointed out
that this can result in long delays for clients connected to a broker
that elects to give an update to a newcomer, and it might be better
for the broker to disconnect clients so they can fail over to another
broker not busy with an update.
There are 3 cases to consider:
- new member joining/getting update, new client: stall or reject?
- established member giving update, new client: stall or reject?
- established member giving update, connected client: stall or
disconnect?
On the 3rd point I would note that it's possible for clients to
disconnect themselves if the broker is unresponsive by using
heartbeats, and that not all clients can fail-over so I'd lean towards
stall on that one, but I think rejecting new clients may make sense here.
Part of the original motivation for stalling is that it makes it easy
to write tests. You can start a broker and immediately start a client
without worrying about waiting till the broker is ready. That's a nice
property but there are other ways to achieve that. Current qpidd -d
returns as soon as the broker is ready to listen for TCP requests,
which may be before the broker is has joined the cluster. We could
change that behavior to wait till all plugins report "ready". For
tests we could also grep the log output for the ready message.
Thoughts appreciated!
I would dis-allow connections to the new broker until it is synced. I
would not bump any active connections, but rather leave that to heartbeat.
One other idea would be to add an option to cluster config which could
specify the preferred nodes to update from, and it would try this list
first. I.e. in a 4 node cluster, all updates are made from node 4
(preferred) if there, and then from an app point of view I connect to
node 1-3 for example. This way updates have no effect on my clients and
if I care about being stalled I set this option. if the prefered node/s
are not running it would just pick one as it does today
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
