Hi,
* Is it possible, somehow, to end a request asynchronously (that is,
outside the event method)?
Because I keep getting "Out of file descriptor errors" since the END
events come so terribly late after I do the close().
you'd still get "too many open files" errors even if it did close
since you are subject to the TIME_WAIT timeout anyway.
In a servlet, it is not possible to control the underlying TCP
connections, I don't think you could do that with regular servlets
either.
You bring up an interesting point, but it will require some serious
thinking to see if this is feasible or usable :)
Filip
Thanks for the answer.
I guess TIME_WAIT would be a bit of a problem. Although the client would
receive the end of stream signal pretty quickly (long before the
TIME_WAIT) and probably close the socket, causing an immediate READ or
END event.
Currently I have found the following solution:
1) the server sends an asynchronous close signal to the client in the
form of some data written to the response outputstream
2) the client closes the socket immediately when it receives this signal
(and I've set the SO_LINGER to true with timeout 0 on the client sockets).
3) the server immediately gets an END event and cleans up
I pass an OutputStream wrapper to my server side application which wraps
the response output stream and synchronizes on all methods, and in the
END event I synchronize using the same lock (the wrapper) around
event.close(). This seems to have eliminated all race conditions,
NullPointerExceptions, AsyncCloseExceptions, and CloseChannelExceptions.
This allows me to do the async close and have the socket dissappear
immediately, solving the out of file descriptor problem for me.
This solution obvioulsy only works because I have control over the
client in my specific situation. In the case that the client is a
browser, such control is not possible.
The request, wait, async response + close pattern seems to be a pretty
common use case though, especially with server side push (AJAX), so it
would still be good to have a solution that works well allways.
Regards,
Sebastiaan
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
