> On March 28, 2013, 7:50 p.m., Alan Conway wrote: > > I'm not completely following this. It looks like declaring an > > overflow-partnership sends messages to queue X to queue Y and vice versa? > > Why would you want to redirect in both directions? Also I'm a bit puzzled > > by the name overflow-partner. What's overflowing? > > Chug Rolke wrote: > There was a PDF attached to the Jira. The essence is that the broker is > providing a real-time delivery service and a consumer goes slow. Rather than > having this consumer queue go too big or drop messages a 'backup agent' steps > in and starts receiving all the consumer's messages on a different queue. The > backup agent is big and fast and buffers the consumer data until some time at > which the consumer queue 'has more room'. Then the backup agent starts > feeding messages into the original queue.
Thanks, that explains it. - Alan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10020/#review18471 ----------------------------------------------------------- On March 26, 2013, 1:54 a.m., Chug Rolke wrote: > > ----------------------------------------------------------- > 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. > > > 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 > ----- > > 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 > >
