You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Adar Dembo (JIRA)" <ji...@apache.org> on 2019/02/28 02:36:00 UTC

[jira] [Created] (KUDU-2718) master_failover-itest when HMS is enabled is flaky

Adar Dembo created KUDU-2718:
--------------------------------

             Summary: master_failover-itest when HMS is enabled is flaky
                 Key: KUDU-2718
                 URL: https://issues.apache.org/jira/browse/KUDU-2718
             Project: Kudu
          Issue Type: Bug
          Components: test
    Affects Versions: 1.9.0
            Reporter: Adar Dembo
         Attachments: master_failover-itest.1.txt

This was a failure in HmsConfigurations/MasterFailoverTest.TestDeleteTableSync/1, where GetParam() = 2, but it's likely possible in every multi-master test with HMS integration enabled.

It looks like there was a leader master election at the time that the client tried to create the table being tested. The master managed to create the table in HMS, but then there was a failure replicating in Raft because another master was elected leader. So the client retried the request on a different master, but the HMS piece of CreateTable failed because the HMS already knew about the table.

Thing is, there's code to roll back the HMS table creation if this happens, so I don't see why the retried CreateTable failed at the HMS with "table already exists". Perhaps this is a case where even though we succeeded in dropping the table from HMS, it doesn't reflect that immediately?

I'm attaching the full log.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)