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 2018/09/12 20:44:00 UTC

[jira] [Created] (KUDU-2576) TlsSocketTest.TestRecvFailure is flaky

Adar Dembo created KUDU-2576:
--------------------------------

             Summary: TlsSocketTest.TestRecvFailure is flaky
                 Key: KUDU-2576
                 URL: https://issues.apache.org/jira/browse/KUDU-2576
             Project: Kudu
          Issue Type: Bug
          Components: security
    Affects Versions: 1.8.0
            Reporter: Adar Dembo
            Assignee: Alexey Serbin


This test seems destined to be flaky in TSAN environments.

The initial sleep is there so that the stop signal to EchoServer is sent while it's blocked inside the echo loop. That appears to be how we can safely assert that one write and one recv both succeed, while the second recv fails.

However, it's possible for EchoServer to be so slow to start that 100 ms isn't enough, and the stop signal reaches it before it enters the loop. Then the first write will fail like this:
{noformat}
/home/jenkins-slave/workspace/kudu-master/3/src/kudu/security/tls_socket-test.cc:230
Failed
Bad status: Network error: BlockingWrite error: failed to write to TLS socket: Connection reset by peer
{noformat}

Alexey said he'd take a look at this.



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