Dealing with out of sequence responses

[Tyler Treat <tt...@gmail.com>]

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

Re: Dealing with out of sequence responses

[Randy Abernethy <ra...@gmail.com>]

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 <be...@gmail.com> 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 <tt...@gmail.com> 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
> >
>

Re: Dealing with out of sequence responses

[Ben Craig <be...@gmail.com>]

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 <tt...@gmail.com> 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
>