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!
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
