Sebastiaan van Erk wrote:
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.
Yes, and for this you don't need Comet, you need "Asynchronous Servlets"
they are somewhat different, although you can achieve the same through
A) Using a regular servlet, and just hold on to the worker thread
B) Using a Comet servlet but with a short timeout.
In order for you to not timeout if your write is way delayed, then
you need to write some bogus data before the timeout happens
As of now, we don't have async servlets on the agenda, and we would need
to see what it takes to make Comet to behave like it.
Filip
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]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
