[
https://issues.apache.org/jira/browse/KUDU-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Berkeley updated KUDU-2576:
--------------------------------
Code Review: http://gerrit.cloudera.org:8080/12758
> 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: Will Berkeley
> Priority: Major
>
> 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)
