n+1 broker race conditions 1.x

[christian-posta]

opening this to track. working on a patch.

what happens is when two brokers get deployed to a container, you can end up with the following:

• both brokers end up trying to startup at roughly the same time
• when each checks to see whether they can_own_pool, both see that they can (since nobody was elected into that spot yet) and this enables their pool in the ClusteredConfig
• so when a master finally does get picked (take_pool) then updates will be fired (fire_pool_changes) which will attempt to update the pool states again. this time one of the ClusteredConfigs/broker will see that it was "kicked out of the pool" and will shutdown its discovery agent.
• sometime after when the disc agent is shutdown, a "CHANGED" event comes through the other groupListener and the group looks like it has 0 members, so the broker that was once elected master is now demoted
• no brokers are running then

[davsclaus]

Wonder what the status of this is for 6.2 ?