[
https://issues.apache.org/jira/browse/KUDU-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16612874#comment-16612874
]
Alexey Serbin commented on KUDU-2576:
-------------------------------------
Another example of failure log:
{noformat}
I0912 16:03:01.451243 46002 tls_socket-test.cc:109] server: negotiation complete
I0912 16:03:01.451436 45715 tls_socket-test.cc:109] client: negotiation complete
I0912 16:03:11.475841 46002 tls_socket-test.cc:165] server echoing 24395776
bytes
src/kudu/security/tls_socket-test.cc:230: Failure
Failed
Bad status: Timed out:
I0912 16:03:19.451289 45715 test_util.cc:131]
-----------------------------------------------
{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: Alexey Serbin
> 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)
