Tamas Kovacs created THRIFT-5515:
-------------------------------------
Summary: 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
Attachments: test.zip
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)
