[
https://issues.apache.org/jira/browse/THRIFT-6107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18097664#comment-18097664
]
Jens Geyer edited comment on THRIFT-6107 at 7/20/26 8:20 PM:
-------------------------------------------------------------
{quote}
A connection must publish reply-bearing requests in the order their frames were
accepted, even when their handlers complete out of order.
{quote}
I wonder if we have any spec about this desired behaviour.
Also, what happens if request A is accepted before B, but B takes only 0,1 s to
complete while A takes way longer, e.g. 2 seconds? Should B wait until A
completed? What if A runs into a deadlock (or near-deadlock experience)? Will
this stall the entire server, because no newer requests can be handled until A
completes?
was (Author: jensg):
{quote}
A connection must publish reply-bearing requests in the order their frames were
accepted, even when their handlers complete out of order.
{quote}
I wonder if we have any spec about this desired behaviour.
Also, what happens if request A is accepted before B, but B takes only 0,1 s to
complete while A takes way longer, e.g. 2 seconds? Should B wait until A
completed? What if A rujns into a deadlock? Will this stall the entire server,
because no newer requests can be handled until A completes?
> Ruby NonblockingServer can send replies out of request order
> ------------------------------------------------------------
>
> Key: THRIFT-6107
> URL: https://issues.apache.org/jira/browse/THRIFT-6107
> Project: Thrift
> Issue Type: Bug
> Components: Ruby - Library
> Reporter: Dmytro Shteflyuk
> Assignee: Dmytro Shteflyuk
> Priority: Major
> Attachments: nonblocking-reply-order.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Problem
> {{Thrift::NonblockingServer}} can read multiple framed requests from one
> connection and assign them to separate worker threads. A worker writes its
> response as soon as its handler finishes. If a later request completes first,
> its reply is written to the shared connection before the earlier reply.
> h3. Client impact
> Clients that intentionally pipeline requests on one connection can receive
> replies in an order different from the request order. The generated Ruby
> client maintains pending sequence IDs in send order, so it can reject such a
> reply as the wrong method or sequence ID.
> Applications that use only the synchronous generated client methods, with one
> request in flight per connection, do not encounter this behavior. Sharing one
> generated client instance between threads is separately unsupported; that is
> not required to reproduce this issue.
> h3. Reproduction
> Use one connection and send two requests without waiting for the first reply:
> {code:ruby}
> client.send_block # handler waits
> handler.block_started.pop
> client.send_greeting(true) # handler completes first
> processor_finished.pop
> # Before the fix, emitted framed reply sequence IDs are [1, 0].
> handler.unblock(1)
> client.recv_block # receives the greeting reply first
> {code}
> h3. Sequence diagram
> !nonblocking-reply-order.png|width=900!
> h3. Expected behavior
> A connection must publish reply-bearing requests in the order their frames
> were accepted, even when their handlers complete out of order. Oneway
> requests, handler failures, connection removal, partial writes, and shutdown
> must not leave a missing sequence that indefinitely blocks later replies.
> Requests on different connections should remain independently concurrent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
