Reich, Matthias wrote:
The NioEndpoint seems to close a connection during the timeout handling.
My client reacts to a connection failure with a resubmit of the last
request,
and I see this in the log:
07.05.2007 22:08:14 comettest.CometServlet event
WARNUNG: BEGIN(16) POST /comettest/comet/request?action=poll&count=1
07.05.2007 22:08:35 comettest.CometServlet event
WARNUNG: ERROR/TIMEOUT(16) POST
/comettest/comet/request?action=poll&count=1
07.05.2007 22:08:35 comettest.CometServlet event
WARNUNG: BEGIN(17) POST /comettest/comet/request?action=poll&count=1
I had a look into the code and found that NioEndpoint.timeout calls
cancelledKey(key, SocketStatus.TIMEOUT,true);
Method cancelledKey processes the timeout event and then closes the
channel.
However, the Javadoc of enum EventSubType says:
TIMEOUT - the connection timed out (sub type of ERROR); note that this
ERROR type is not fatal, and the connection will not be closed unless
the servlet uses the close method of the event.
hmm, not sure I agree with the docs. let me check on that.
in the meantime, why don't you set a much higher timeout value
for the NIO connector you can do this on a per-connection basis.
just do event.setTimeout during the BEGIN event.
Filip
My servlet does not close the event in case of a TIMEOUT, and thus the
CoyoteAdapter won't recycle the processor. The consequence is that
Tomcat runs out of memory after a while if my asynchronous response
provider thread often waits longer than the connection timeout before
sending an answer.
you're servlet SHOULD ALWAYS call event.close upon any type of error.
According to a note which was still present in the Tomcat 5.5 server.xml
file, I tried to set the connectionTimeout value to 0 to disable
connection timeouts, but that does no longer seem to work with Tomcat 6,
at least not with the Nio connector.
see the note about per-connection timeout, also, you can set
socket.soTimeout
see the documentation
Thus, I think this behavior of the NioEndpoint must be considered a bug.
(Also, the Apr connector does not close the connection upon a TIMEOUT
event.)
If it should not be possible to provide a short term solution which
keeps the connection open, perhaps the behavior of NioEndpoint.timeout
can be modified to signal a DISCONNECT instead of a TIMEOUT, even if it
was the server and not the client that disconnected. This would allow
the Servlet and the CoyoteAdapter to clean up more properly.
Matthias
---------------------------------------------------------------------
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]