thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Duxbury <br...@rapleaf.com>
Subject Re: Java Server Does Not Close Sockets immediately for oneway methods
Date Thu, 11 Feb 2010 20:58:31 GMT
Well put, sir.

On Thu, Feb 11, 2010 at 11:56 AM, Mark Slee <mslee@facebook.com> wrote:

> I think the request should still be processed at that point, so that any
> side-effects happening on the server do take place. IMO, a close() in that
> situation signifies that the client doesn't care about the response, but I
> think it would be overstepping to assume it means the request should be
> canceled.
>
> A trivial example is something like service.incrementThenReturn().
> Basically, I think the server should do its best to always make sure that
> increment happens when a client request gets through.
>
> For the sake of argument, the counter-example here is something like
> service.returnThenIncrement(), which implies that you don't want to
> increment if you're not going to be able to successfully return.
>
> My opinion here is that this is always a flawed design. Since the server
> can NEVER guarantee that the response will be received, because the
> transport layer can always fail. If one wants to know the response was
> returned, then the increment() must be issued in a separate, follow-on call
> by the client after receiving the first response.
>
> Therefore, I would consider the counter-example an invalid design and
> implement the 1st model -- servers ought to fully process any and all valid
> requests received in their entirety, regardless of transport state.
>
> My 2c,
> mcslee
>
> -----Original Message-----
> From: Bryan Duxbury [mailto:bryan@rapleaf.com]
> Sent: Thursday, February 11, 2010 11:38 AM
> To: thrift-user@incubator.apache.org
> Subject: Re: Java Server Does Not Close Sockets immediately for oneway
> methods
>
> On Thu, Feb 11, 2010 at 11:28 AM, Mark Slee <mslee@facebook.com> wrote:
>
> > Any patch to implement early-closing on the server-side should NOT depend
> > upon the type of method invoked, it should purely be based upon detecting
> an
> > explicit socket close from the client.
> >
>
> Agreed, with the caveat that a non-oneway request coming from a closed
> socket cannot be responded to. It's worth considering whether or not you
> should even process the request at this point.
>

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