[CONTROLLER-1671] Rework transaction cohorts to better support immediate completion Created: 12/May/17  Updated: 25/Jul/23

Status: Confirmed
Project: controller
Component/s: clustering
Affects Version/s: None
Fix Version/s: None

Type: Improvement
Reporter: Robert Varga Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


 Description   

ShardDataTree's transaction pipelining can trigger a long chain of immediate completions, which can eat eat up the stack as demonstrated in CONTROLLER-1620.

In that particular case we are effectively dealing with list traversal (pending transactions in startPreCommit) being done one entry at a time, with each entry eating into the stack:

at org.opendaylight.controller.cluster.datastore.ShardDataTree.processNextPending(ShardDataTree.java:762)
at org.opendaylight.controller.cluster.datastore.ShardDataTree.processNextPendingTransaction(ShardDataTree.java:707)
at org.opendaylight.controller.cluster.datastore.ShardDataTree.startPreCommit(ShardDataTree.java:828)
at org.opendaylight.controller.cluster.datastore.SimpleShardDataTreeCohort.preCommit(SimpleShardDataTreeCohort.java:115)
at org.opendaylight.controller.cluster.datastore.ChainedCommitCohort.preCommit(ChainedCommitCohort.java:63)
at org.opendaylight.controller.cluster.datastore.FrontendReadWriteTransaction.successfulDirectCanCommit(FrontendReadWriteTransaction.java:212)
at org.opendaylight.controller.cluster.datastore.FrontendReadWriteTransaction$5.onSuccess(FrontendReadWriteTransaction.java:200)
at org.opendaylight.controller.cluster.datastore.FrontendReadWriteTransaction$5.onSuccess(FrontendReadWriteTransaction.java:197)
at org.opendaylight.controller.cluster.datastore.SimpleShardDataTreeCohort.successfulCanCommit(SimpleShardDataTreeCohort.java:183)
at org.opendaylight.controller.cluster.datastore.ShardDataTree.lambda$processNextPendingTransaction$0(ShardDataTree.java:718)
at org.opendaylight.controller.cluster.datastore.ShardDataTree.processNextPending(ShardDataTree.java:762)
at org.opendaylight.controller.cluster.datastore.ShardDataTree.processNextPendingTransaction(ShardDataTree.java:707)
at org.opendaylight.controller.cluster.datastore.ShardDataTree.startPreCommit(ShardDataTree.java:828)
at org.opendaylight.controller.cluster.datastore.SimpleShardDataTreeCohort.preCommit(SimpleShardDataTreeCohort.java:115)
at org.opendaylight.controller.cluster.datastore.ChainedCommitCohort.preCommit(ChainedCommitCohort.java:63)
at org.opendaylight.controller.cluster.datastore.FrontendReadWriteTransaction.successfulDirectCanCommit(FrontendReadWriteTransaction.java:212)
at org.opendaylight.controller.cluster.datastore.FrontendReadWriteTransaction$5.onSuccess(FrontendReadWriteTransaction.java:200)
at org.opendaylight.controller.cluster.datastore.FrontendReadWriteTransaction$5.onSuccess(FrontendReadWriteTransaction.java:197)
at org.opendaylight.controller.cluster.datastore.SimpleShardDataTreeCohort.successfulCanCommit(SimpleShardDataTreeCohort.java:183)
at org.opendaylight.controller.cluster.datastore.ShardDataTree.lambda$processNextPendingTransaction$0(ShardDataTree.java:718)
at org.opendaylight.controller.cluster.datastore.ShardDataTree.processNextPending(ShardDataTree.java:762)

I believe this can be refactored so that we have a simple while() loop executing canCommit/preCommit(), which communicate back their immediate result. The loop would bail as soon as it encounters an async operation.
Generated at Wed Feb 07 19:56:09 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.