[jira] [Resolved] (THRIFT-5515) Oneway requests can stuck in TNonblockingServer with TSSLSocket

["Jens Geyer (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jens Geyer resolved THRIFT-5515.
--------------------------------
    Fix Version/s: 0.17.0
         Assignee: Tamas Kovacs 
       Resolution: Fixed

> Oneway requests can stuck in TNonblockingServer with TSSLSocket
> ---------------------------------------------------------------
>
>                 Key: THRIFT-5515
>                 URL: https://issues.apache.org/jira/browse/THRIFT-5515
>             Project: Thrift
>          Issue Type: Bug
>          Components: C++ - Library
>    Affects Versions: 0.15.0
>         Environment: thrift: 0.15.0
> openssl: 1.0.2k
> libevent: 2.0.21-stable method epoll
>  
>            Reporter: Tamas Kovacs 
>            Assignee: Tamas Kovacs 
>            Priority: Major
>             Fix For: 0.17.0
>
>         Attachments: test.zip
>
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> C++ TNonblockingServer processes the requests one by one. The processing of one request starts when an event for the given socket is triggered by libevent.
> If TSSLSocket used, the openssl library may read all the available data from the socket which potentially contain more requests.
> The first request is processed by TNonblockingServer::workSocket.
> But after that since only oneway requests are used no send happens and the socket receive buffer is already empty, so no any event is triggered by libevent.
> This means the processing of the further request already buffered by openssl will happen only when a new request arrives to the socket. 
> There is a little test client/server attached to show the problem. The output from server_rpcgw is the following:
> 17:23:35 message1
> 17:23:37 message2
> 17:23:37 message3
> The message2 was sent by the client at the same time like message1, but got processed by the server just when the message3 arrived.
> In the attached wireshark capture the frame #10 contains the message1 and message2 the #12 contains the message3.
> In the code there is already a comment about this case after the thrift frame size is read:
> https://github.com/apache/thrift/blob/0b29261a4f3c6882ef3b09aae47914f0012b0472/lib/cpp/src/thrift/server/TNonblockingServer.cpp#L480
> It is not clear why no similar check happens after the thrift frame content is read.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)