[
https://issues.apache.org/jira/browse/THRIFT-6107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmytro Shteflyuk updated THRIFT-6107:
-------------------------------------
Attachment: nonblocking-reply-order.png
> 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, nonblocking-reply-order.svg
>
>
> 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.svg|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)
