[
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
