Uploaded image for project: 'controller'
  1. controller
  2. CONTROLLER-1671

Rework transaction cohorts to better support immediate completion

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • None
    • None
    • clustering
    • None
    • Operating System: All
      Platform: All

      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.

            Unassigned Unassigned
            rovarga Robert Varga
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated: