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