Well put, sir. On Thu, Feb 11, 2010 at 11:56 AM, Mark Slee <[email protected]> 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:[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. >
