You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Chuck Rolke (JIRA)" <ji...@apache.org> on 2013/03/14 19:16:12 UTC
[jira] [Resolved] (QPID-4616) C++ Broker needs consistent way to
freeze traffic on a per-exchange basis
[ 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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org