[ 
https://issues.apache.org/jira/browse/MESOS-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15816895#comment-15816895
 ] 

Benjamin Hindman commented on MESOS-6802:
-----------------------------------------

Committed https://reviews.apache.org/r/53802:

{code}
commit d4185d4a117d9cba32d80993d14fcefb566cd9f9
Author: Greg Mann <[email protected]>
Date:   Tue Jan 10 18:23:45 2017 -0800

    Eliminated an EOF race condition in libprocess SSL socket.
    
    Previously, it was possible for an SSL socket to either:
    1) Fail to receive an EOF if the EOF event was received when
       there was no pending recv() request.
    2) Fail to receive all data sent on the sending side if an
       EOF event was received before all sent data was read.
    
    This patch eliminates these race conditions to ensure reliable
    receipt of both sent data and EOFs.
    
    Review: https://reviews.apache.org/r/53802/
{code}

> SSL socket can lose bytes in the case of EOF
> --------------------------------------------
>
>                 Key: MESOS-6802
>                 URL: https://issues.apache.org/jira/browse/MESOS-6802
>             Project: Mesos
>          Issue Type: Bug
>          Components: libprocess
>            Reporter: Greg Mann
>            Assignee: Greg Mann
>              Labels: libevent, libprocess, ssl
>
> During recent work on SSL-enabled tests in libprocess (MESOS-5966), we 
> discovered a bug in {{LibeventSSLSocketImpl}}, wherein the socket can either 
> fail to receive an EOF, or lose data when an EOF is received.
> The {{LibeventSSLSocketImpl::event_callback(short events)}} method 
> immediately sets any pending {{RecvRequest}}'s promise to zero upon receipt 
> of an EOF. However, at the time the promise is set, there may actually be 
> data waiting to be read by libevent. Upon receipt of an EOF, we should 
> attempt to read the socket's bufferevent first to ensure that we aren't 
> losing any data previously received by the socket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to