BUG 3019 : Fix Operation throttling for modification batching scenarios
This patch straightens out where exactly limiting is done.
A TransactionProxy creates a TransactionContext for every shard on
which a transaction needs to be done. There are 3 types of TransactionContexts.
NoOpTransactionContext, LocalTransactionContext and RemoteTransactionContext.
When a operation is done on TransactionProxy it does not know which of these
TransactionContexts it should create so it first createas a TransactionContextWrapper.
All operations on TransactionProxy are then queued up in the TransactionContextWrapper
till we determine which TransactionContext to create. This patch creates an
OperationLimiter per TransactionContextWrapper. Everytime an operation is enqueued
we acquire a permit.
When the TransactionContext is finally created we do different things depending on
the TransactionContext. For NoOp and Local TransactionContexts we completely ignore
the limiter - that is for these TransactionContexts there is no limiting done. For
RemoteTransactionContext we do limiting. RemoteTransactionContext does not acquire
Operation permits till it is made visible by the TransactionContextWrapper - this is
signaled be the setting of the handOffComplete flag in AbstractTransactionContext.
After that RemoteTransactionContext takes over the business of acquiring permits.
OperationLimiter which also serves as the Operation completion handler is the only
component that releases the permits.
Another thing which this patch addresses is which configuration option we use for
operation limiting. We now use ShardBatchedModificationCount instead of the mailbox
limit from akka.conf. This removes the possibility of mis-configuration where
making ShardedBatchedModificationCount higher than mailbox limit could cause
unexpected blocking.
Change-Id: I571ba5278630e5166be6bcb3ff8e1c527c5e3343
Signed-off-by: Moiz Raja <moraja@cisco.com>
(cherry picked from commit
21ccb7510c28e824d6441d48604aec7467d44710)
Code Review / controller.git / commit