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:[email protected]] Sent: Thursday, February 11, 2010 11:38 AM To: [email protected] Subject: Re: Java Server Does Not Close Sockets immediately for oneway methods On Thu, Feb 11, 2010 at 11:28 AM, Mark Slee <[email protected]> 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.
