[
https://issues.apache.org/jira/browse/KUDU-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793811#comment-16793811
]
Will Berkeley edited comment on KUDU-2576 at 3/15/19 5:49 PM:
--------------------------------------------------------------
Various issues resolved by
{noformat}
04e584c62 Increase timeout in tls_socket-test
bedc701f2 Check result status of Socket::GetPeerAddress in TlsSocket::Recv
df4fd91fd KUDU-2576: TlsSocketTest.TestRecvFailure is flaky
{noformat}
was (Author: wdberkeley):
Various issues resolved by
{{noformat}}
04e584c62 Increase timeout in tls_socket-test
bedc701f2 Check result status of Socket::GetPeerAddress in TlsSocket::Recv
df4fd91fd KUDU-2576: TlsSocketTest.TestRecvFailure is flaky
{{noformat}}
> 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
> Fix For: 1.10.0
>
>
> 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)
