thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyler Treat <ttrea...@gmail.com>
Subject Re: Dealing with out of sequence responses
Date Fri, 30 Oct 2015 14:10:45 GMT
I guess my main question then is what the best practice is when dealing
with timeouts. It sounds like if a request times out, you should disconnect
the client and reconnect, which is an unfortunate amount of overhead for
what is potentially a transient error.

Thanks,
Tyler

On Fri, Oct 30, 2015 at 2:54 AM Jens Geyer <jensgeyer@hotmail.com> wrote:

> The single most important thing that comes to my mind is this: What if the
> client is aware of this and *wants* both responses?
>
> If the framework automatically and implicitly drops older requests or
> refuses to deal with responses coming in a different order, how do you
> handle that? But if that logic is one layer above Thrift, it is much easier
> implement whatever model you need.
>
> There are situations for each model, IMHO. If we plan to do anything here,
> we should add comfort, but keep all possibilities.
>
> Have fun,
> JensG
> ________________________________
> Von: Tyler Treat
> Gesendet: 30.10.2015 01:06
> An: user@thrift.apache.org
> Betreff: Dealing with out of sequence responses
>
> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message