[ https://issues.apache.org/jira/browse/QPID-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chuck Rolke resolved QPID-4616. ------------------------------- Resolution: Won't Fix A feature proposal required the exchange locking proposed in this issue. That feature has withdrawn the requirement thus rendering this issue unnecessary. > C++ Broker needs consistent way to freeze traffic on a per-exchange basis > ------------------------------------------------------------------------- > > Key: QPID-4616 > URL: https://issues.apache.org/jira/browse/QPID-4616 > Project: Qpid > Issue Type: New Feature > Components: C++ Broker > Affects Versions: 0.20 > Reporter: Chuck Rolke > Assignee: Chuck Rolke > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org