The JavaScript client is the one (and only I think) exception to Ben's comment. Due to the async only nature of things in JavaScript, sequence numbers are relied upon to connect responses to callbacks when multiplexing is used. Not a general case but demonstrates the concept in action.
On Thu, Oct 29, 2015 at 7:24 PM, Ben Craig <[email protected]> wrote: > Hi Tyler, > The current code in mainline Thrift does not support that use case. > Basically, if a call times out, then you need to throw away the client > object and reconnect. In addition, most clients do not allow > multi-threaded access, so you can't interleave a call to ping and add. > > With that being said, the wire protocol does support the use case, there > just isn't any code to support it. Discarding outdated responses is > reasonable, but you would need to make that happen by either modifying > Thrift yourself, or hand crafting the client code to do so. > > On Thu, Oct 29, 2015 at 7:06 PM, Tyler Treat <[email protected]> wrote: > > > Hi, > > > > I'm curious about Thrift's design around out of sequence responses. > > Consider the sequence of events in this contrived example: > > > > Client calls ping() > > Server receives ping() and sleeps a few seconds > > Client ping() times out > > Client calls add() > > Server finishes sleeping and responds to ping() > > Client gets out of sequence response error (received ping() response when > > expecting add() response) > > > > It seems like what Thrift should do is drop responses with previous > > sequence ids? I.e. if ping() sequence id is 1 and it times out and I call > > add() which expects sequence id 2, I should drop the response with id 1. > > > > Am I thinking about this correctly? > > > > Thanks, > > Tyler > > >
