setting a timeout doesn't mean you're gonna get a timeout in exactly 5
seconds, it means that after 5 seconds the server can time it out.
the server is still only checking for timeouts at certain intervals.
the way you describe it, like connectionTimeout drives your timeout,
that would mean you
Anyone else experiencing comet timeout problems with the nio connector
and the latest 6.0.x trunk?
My cometEvent.setTimeout(...) setting is ignored, but I do receive
comet timeouts based on the connectionTimeout setting for the nio
connector. Setting the connectionTimeout to 10 secs gives me a co
Using the nio connector from the latest 6.0.x trunk, I'm failing to
receive any comet timeouts. I set the comet timeout to 5 secs but,
after waiting much longer than 5 secs, the only two events I receive
are begin and read.
event: BEGIN, subtype: null
for servlet: com.seekspeak.server.deb
The time when it is called without a subtype, is if the
application(servlet) has an unhandled exception
in terms of timeout, that should work just dandy, unless the client
disconnects, at which point at which point you might get a subtype of
IOEXCEPTION, or CLIENT_DISCONNECT
depending on the
Using the NIO connector: protocol="org.apache.coyote.http11.Http11NioProtocol".
I'll add response.flushBuffer() and see if that helps.
The tomcat version I was testing against was current with svn as of
last Friday. I just updated and the only files that are new are:
catalina.policy
STATUS.txt
c
what connector are you using?
I would try to use response.flushBuffer when you wanna flush it out (ie
after you've written to and flushed your stream).
also, there have been some bug fixes, that you can get from SVN, or wait
for 6.0.16 to come out
Filip
Peter Warren wrote:
I have some come
