kudu-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aw...@apache.org
Subject [kudu] 01/03: test: deflake TestFailedTServerInMaintenanceModeDoesntRereplicate
Date Wed, 02 Oct 2019 06:31:39 GMT
This is an automated email from the ASF dual-hosted git repository.

awong pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/kudu.git

commit 51ccb1165a1ca6f243dfdcbf86fe6af3abe7fc77
Author: Andrew Wong <awong@cloudera.com>
AuthorDate: Tue Oct 1 18:34:04 2019 -0700

    test: deflake TestFailedTServerInMaintenanceModeDoesntRereplicate
    Ongoing TestWorkloads don't like it when the only master gets restarted. That
    made the test fail with such errors as:
    F1002 01:26:04.854351 26289 test_workload.cc:255] Network error: LookupRpc { table: 'test-workload',
partition-key: (RANGE (key): 1143140152), attempt: 1 } failed: Client connection negotiation
failed: client connection to connect: Connection refused (error 111)
    So I've allowed network errors in the TestWorkload. Without this, this
    failed 3/5000 times in debug mode. With it, it passed 4999/5000 times
    (failure due to KUDU-2431).
    Change-Id: Ia9f52a65ea76996c503f922af3e068048142e5f5
    Reviewed-on: http://gerrit.cloudera.org:8080/14342
    Reviewed-by: Adar Dembo <adar@cloudera.com>
    Tested-by: Kudu Jenkins
 src/kudu/integration-tests/maintenance_mode-itest.cc | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/kudu/integration-tests/maintenance_mode-itest.cc b/src/kudu/integration-tests/maintenance_mode-itest.cc
index f982586..c3bb288 100644
--- a/src/kudu/integration-tests/maintenance_mode-itest.cc
+++ b/src/kudu/integration-tests/maintenance_mode-itest.cc
@@ -219,8 +219,12 @@ TEST_F(MaintenanceModeRF3ITest, TestFailedTServerInMaintenanceModeDoesntRereplic
   // Create the table with three tablet servers and then add one so we're
   // guaranteed that the replicas are all on the first three servers.
+  // Restarting our only master may lead to network errors and timeouts, but
+  // that shouldn't matter w.r.t maintenance mode.
   TestWorkload create_table(cluster_.get());
+  create_table.set_network_error_allowed(true);
+  create_table.set_timeout_allowed(true);
   // Add a server so there's one we could move to after bringing down a

View raw message