[QPID-4616] C++ Broker needs consistent way to freeze traffic on a per-exchange basis

• Type: New Feature
• Status: Closed
• Priority: Major
• Resolution: Won't Fix
• Affects Version/s: 0.20
• Component/s: C++ Broker
• Assignee: Charles E. Rolke
• Reporter: Charles E. Rolke
• Created: 01/Mar/13 15:07
• Updated: 20/Aug/13 19:56
• Resolved: 14/Mar/13 18:14

Description

Some applications may require "freezing" the bindings in an exchange so that changes to the exchange are applied between messages. As the exchanges are designed today this is not possible. This issue tracks a method to provide the exchange locking feature.

There are four basic exchange types and three locking strategies:

• FanOut - has no locking at the exchange level. Locks for fanout are provided in the CopyOnWriteArray class.
• Direct and Headers - have simple per-exchange lock. There is no differentiation between read lock and write lock.
• Topic - has RWlock. Binding readers and consumers take out the Rlock and binding writers take out the Wlock.

The proposal is for all exchanges to use the RWlock the way Topic Exchange uses it. To implement this the following steps are taken:

• Move Topic exchange RWlock up into the parent exchange class and call it 'bindingLock'.

• In Topic exchange take RWlock out of the derived class and use the parent's lock.
• In Direct and Headers exchanges change the semantics of the current lock to use the Topic exchange pattern.
• In FanOut exchange add locks at the same places as in the other exchanges except only use Rlock. FanOut receives the locking it needs from the CopyOnWriteArray and does not need anything else. By adding only Rlocks threads will never block in the normal case. However, the Rlocks are the hooks that the new application will need to freeze the exchange when that app takes out the Wlock.

A review to support this proposal is on its way.