This is an automated email from the ASF dual-hosted git repository. bankim pushed a commit to branch branch-1.15.x in repository https://gitbox.apache.org/repos/asf/kudu.git
commit 8c59dcd394ba5bd3349de0d20c0526cf014e523b Author: Alexey Serbin <[email protected]> AuthorDate: Mon Jun 7 23:30:45 2021 -0700 [test] make new scenario in security-itest more robust This patch makes the newly introduced test scenario SecurityITest.TxnSmokeWithDifferentUserTypes more robust and stable. With awaiting for the first transaction to finalize, now there is no risk for aborting the second transaction in case of a race. Before this patch, if it took a long time to finalize aborting the former transaction, the deadlock prevention logic would automatically abort the latter one, failing the test scenario. Before this fix, 1/4 (one if four) of runs failed if running with --stress_cpu_threads=16. With this fix, I didn't see a failure in hundreds of runs. Change-Id: Ie99ad41a7a161f9046ba894c072eb92150f0e0e2 Reviewed-on: http://gerrit.cloudera.org:8080/17559 Tested-by: Kudu Jenkins Reviewed-by: Andrew Wong <[email protected]> (cherry picked from commit 598304262439fed0819169d6b1a6bc56020a5eea) Reviewed-on: http://gerrit.cloudera.org:8080/17562 Tested-by: Andrew Wong <[email protected]> Reviewed-by: Bankim Bhavsar <[email protected]> --- src/kudu/integration-tests/security-itest.cc | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/kudu/integration-tests/security-itest.cc b/src/kudu/integration-tests/security-itest.cc index a4486dd..c2d6bd2 100644 --- a/src/kudu/integration-tests/security-itest.cc +++ b/src/kudu/integration-tests/security-itest.cc @@ -359,6 +359,20 @@ TEST_F(SecurityITest, TxnSmokeWithDifferentUserTypes) { ASSERT_OK(smoke_starter(&table, &txn)); ASSERT_OK(txn->Rollback()); + // Wait for the transaction to complete the rollback phase. This is useful + // because the next sub-scenario below starts a new transaction as well, + // and in case of a race it may happen that the transaction below starts + // before this one finalizes its abort phase. Both transactions attempt + // to lock the same partition(s), so the latter is automatically aborted + // by the deadlock prevention logic. + ASSERT_EVENTUALLY([&]{ + bool is_complete = false; + Status completion_status; + ASSERT_OK(txn->IsCommitComplete(&is_complete, &completion_status)); + ASSERT_TRUE(is_complete); + ASSERT_TRUE(completion_status.IsAborted()) << completion_status.ToString(); + }); + // Read the inserted row back. ASSERT_EQ(0, CountTableRows(table.get())); }
