----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10020/ -----------------------------------------------------------
(Updated March 26, 2013, 1:54 a.m.) Review request for qpid, Gordon Sim and Ted Ross. Changes ------- This version does two things that greatly simplify the operation: 1. Only two queues are involved: the source queue and its backup queue. There is no list of backup target queues. 2. Messages for the queues are essentially swapped at the Queue::deliver level. There are no queue attributes to describe a backup queue. Queues are all normal. Exchanges and bindings are unaware of any changes. To effect a backup operation, a broker method that names the two queues is invoked. If the queues pass a series of checks then each queue gets a pointer to its partner queue. In function Queue::deliver the pointer is checked. If null then the message goes to the current queue else the message goes to the backup queue. In order for the backup engine to put messages back on to the original queue there is no need for a backup exchange or more bindings. The backup engine simply puts the the messages into the backup queue. By virture of the swap the messages then go back into the original queue. The patch presented here is still missing protections around queue deletions. It also needs a way to get out of backup state. Description ------- To get a true 'atomic rebind' one should (1) freeze all traffic going through all exchanges that have bindings to be changed. Failing that, one could (2) freeze all traffic going through each exchange while that exchange's bindings are changed. A third option would be (3) to freeze each individual binding while it is moved. Options (1) and (2) require per-message locking at the exchange level; these locks do not exist today and adding them would undoubtedly introduce performance degredation. For discussion please see https://issues.apache.org/jira/browse/QPID-4616 and review comments at https://reviews.apache.org/r/9698/ Option (3) requires no new locking and could leverage the locking methods that the exchanges already use. The change proposed here is a prototype that implements lightweight strategy #3. This review exposes what the feature is trying to accomplish and the basic framework is complete. It has: * Queue settings and status. * Management method to trigger the rebind. * Exchange methods to effect the rebind for each exchange type. * Broker changes to handle queues in the 'rebound' state where bind/unbind operations on them actually go to other queues. * Some test suite code to trigger the rebind method and its error paths. * A qpid.rebind exchange for backup agents to use to refill queues that are in rebind state and not accessable through normal bindings. Before this feature could transition to 'Ship It' it still needs: * An ACL property to control specification of rebind queues. * A handler for queue deletion while the queue is part of a rebind set. * Code to restore a queue from rebind state back to normal. * Proof that traffic can be properly recovered through a rebind This addresses bug QPID-4650. https://issues.apache.org/jira/browse/QPID-4650 Diffs (updated) ----- trunk/qpid/cpp/src/qpid/broker/Broker.h 1460944 trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1460944 trunk/qpid/cpp/src/qpid/broker/Queue.h 1460944 trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1460944 trunk/qpid/cpp/src/tests/queue_rebind.py PRE-CREATION trunk/qpid/cpp/src/tests/run_queue_rebind PRE-CREATION trunk/qpid/specs/management-schema.xml 1460944 trunk/qpid/tools/src/py/qpidtoollibs/broker.py 1460944 Diff: https://reviews.apache.org/r/10020/diff/ Testing ------- Several tests to exercise rebind code paths. Thanks, Chug Rolke
