Hi Daniel,
From the JVM-level, there's doesn't appear to be any other way to
detect this condition outside of
trying to read/write from the socket. There are some low-level actions
you can take to peek at the
socket without taking reading any data, but these aren't exposed at our
level.
These long running HTTP requests. Do you suspend them?
> Daniel Feist <mailto:dfeist_at_gmail.com>
> March 3, 2017 at 10:32
> Hi,
>
> Any thoughts on how it might be possible with Grizzly to close server
> socket as soon as client prematurely closing by sending "FIN" rather
> than only closing it only after processing of the current READ event
> is complete?
>
> The issue I have is that in some use cases processing HTTP requests
> may take a long time and clients may timeout before request is
> complete. In this scenario a socket it left it CLOSE_WAIT for each
> premature client close until the request completes fully using
> unnecessary file descriptors during this time.
>
> I've looked at the code and both with SameThread and Worker
> IOStrategies the fact that future reads are delayed until current read
> is complete seems to be by design, and it makes sense apart from in
> this case.
>
> The HTTP spec says:
>
> "8.1.4 When a client or server wishes to time-out it SHOULD issue a
> graceful close on the transport connection. Clients and servers SHOULD
> both constantly watch for the other side of the transport close, and
> respond to it as appropriate. If a client or server does not detect
> the other side's close promptly it could cause unnecessary resource
> drain on the network."
>
> In a way, Grizzly isn't constantly watching for this situation,
> because it will only respond to client disconnection once any current
> processing is complete.
>
> Any thoughts on how to monitor and react to this more continuously to
> free up sockets quicker in this situation, or if you think the current
> behavior is sufficient.
>
> thanks,
> Dan