THRIFT-6021: Make C++ HTTP client work with oneway requests

[kpumuk]

When making a oneway RPC call, HTTP client closes the HTTP connection so the unread HTTP response cannot poison the next RPC.

Caution

HTTP client does not really have a semantics of "fire and forget", so this is the simplest (but maybe a bit drastic) measure. Maybe calling readMoreData(); readEnd() would make more sense?

• Did you create an Apache Jira ticket? THRIFT-6021
• If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
• Did you squash your changes to a single commit? (not required, but preferred)
• Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"?
• If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.

[Jens-G]

Somehow that sounds weird. Also, assumed I do a lot of oneway calls, what would be the performance impact?

[kpumuk]

Somehow that sounds weird. Also, assumed I do a lot of oneway calls, what would be the performance impact?

Oh for sure it is undeniably weird. The PR is mostly to gather ideas on how to address it, and which side must handle :-)

Here is an example: https://github.com/kpumuk/thrift/actions/runs/26243739717/job/77238383058 . From rb-cpp_compact_http-ip_client.log:

testClient.testOneway(1) =>  success - took 0.03 ms
re-test testI32(-1)terminate called after throwing an instance of 'apache::thrift::transport::TTransportException'
  what():  No more data to read.
===============================================================================
Return code: -6 (negative values indicate kill by signal)
Test execution took 1.2 seconds.
Thu May 21 18:17:57 2026

[kpumuk]

I highly suspect that these are related too:

• https://github.com/apache/thrift/blob/master/test/known_failures_Linux.json#L309-L316
• https://github.com/apache/thrift/blob/master/test/known_failures_Linux.json#L648 (and other py-cpp-*-http-ip known failures)

[kpumuk]

Java suffers from the same issue https://github.com/kpumuk/thrift/actions/runs/26251658457/job/77265909596:

testClient.testMultiException("success", "test 3") =>  {{"test 3"}}
testOneway(3)...Oneway test took too long to execute failed: took 3004ms
oneway calls are 'fire and forget' and therefore should not cause blocking.
Some transports (HTTP) have a required response, and typically this failure
means the transport response was delayed until after the execution
of the RPC.  The server should post the transport response immediately and
before executing the RPC.
*** FAILURE ***
Total time: 3274766us
Min time: 3274766us
Max time: 3274766us
Avg time: 3274766us

Sample TSimpleJSONProtocol output:
{"userMap":{"5":5,"8":8},"xtructs":[{"string_thing":"Goodbye4","byte_thing":4,"i32_thing":4,"i64_thing":4},{"string_thing":"Hello2","byte_thing":2,"i32_thing":2,"i64_thing":2}]}
===============================================================================
Return code: 1 (negative values indicate kill by signal)
Test execution took 3.5 seconds.
Thu May 21 20:52:21 2026

[kpumuk]

Alright, I think there are 2 bugs:

• C++ does not drain the response, which HTTP server generates
• Ruby does not return immediately, instead running the handler synchronously

Will see how to fix it...