I believe at this point the changes made to MRG queue bindings are not atomic, which might create a problem in HA environments in case of recovery/failover.
Bind requests should be idempotent though, therefore a request can be safely retried on failover if it had not completed successfully; if it does complete succesfully it will have been replicated. However, a separate issue is that multiple bind requests can not be made atomic w.r.t. the incoming message stream. E.g. Assume there is an exchange, e, and two queues q-a and q-b, with q-a initially bound to e by key 'k'. We now wish to change the route for messages with that key such that they now go to q-b. If we do bind(e, 'k', q-b), then unbind(e, 'k', q-a), its possible that a message arriving after the bind and before the unbind will be added to both queues. If on the other hand we do the unbind before the bind, a message arriving between these two operations may be lost. Can I clarify whether it is this latter case that is of concern here?
The latter is my concern.
Created attachment 328080 [details] Proposed change and simple test The attached patch adds a 'qpid.exclusive-binding' option to the exchange-bind method for a direct exchange. If this key is present in the arguments to the bind, the exchange in question will ensure that this is the only binding with the given key. In other words if you issue a bind with this option specified, it acts as an atomic 'rebind', deleting any existing binding with that key and adding in the requested binding.
Committed as r732297
RHTS test qpid_compilation_tests and manual testing on RHEL 4.7 / 5.3 i386 / x86_64 proved that exclusive binding is implemented and working as tested with ClientSessionTest.cpp's testExclusiveBinding on packages: qpidd-0.4.744917-1.el4/5, rhm-0.4.3116-3.el4/5 ->VERIFIED
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0434.html