Jens Geyer created THRIFT-6216:
----------------------------------
Summary: C++: TNonblockingServer sends no reply when a call fails
before anything is written
Key: THRIFT-6216
URL: https://issues.apache.org/jira/browse/THRIFT-6216
Project: Thrift
Issue Type: Bug
Components: C++ - Library
Reporter: Jens Geyer
h2. What happens
When a request's task ends without writing anything to the output transport,
{{TNonblockingServer}} treats the request as oneway and sends nothing back. A
client that made an ordinary call waits for a reply that never comes -- until
its own receive timeout, or indefinitely without one.
h2. Why
{{TConnection::transition()}}, {{case APP_WAIT_TASK}}
({{TNonblockingServer.cpp:703}} on master), decides whether a reply is owed
from the size of the output alone:
{code:cpp}
// 4 bytes were reserved for frame size
if (writeBufferSize_ > 4) {
... // send the result
}
// In this case, the request was oneway and we should fall through
{code}
The server cannot know that. That comment is the only mention of oneway in
{{TNonblockingServer.h}} and {{TNonblockingServer.cpp}}; only the processor
sees whether the message was {{T_ONEWAY}} or {{T_CALL}}. A method that returns
nothing is not a oneway method -- it still owes a reply, and an exception is
one of the replies it can owe.
It happens when processing fails outside the generated per-function {{try}},
which would otherwise write the exception reply itself -- for example while the
arguments are being read. {{Task::run()}} catches the exception, logs it and
notifies the I/O thread; nothing has been written, so the connection goes back
to waiting for the next request.
The inline path in the same file (no thread manager) closes the connection on
the same failure, so the two paths already disagree.
h2. Suggested fix
Do not infer oneway from the output size. Either let the task report that
processing failed and close the connection, as the inline path does, or carry
the message type the processor read.
_Drafted with AI assistance (Claude Opus 5); reviewed and filed by Jens Geyer._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
