[ 
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)

Reply via email to