I'm re-writing an application to use the CometProcessor interface.
Generally things are working but despite several late evenings
single-stepping through the connector code, I'm still unclear
on one issue and would appreciate some education:

In my debugging I'm using NIO (production deployment is
intended to use Linux and APR but for now my question pertains to
my experiences with NIO on the Windows desktop).

My application receives a BEGIN event and stores the
event object, response and so on for later use to respond
to the client, much like the example code.
Until that time, which may be many minutes in
the future, it sends nothing back to the client.

I see EventSubType.TIMEOUT events delivered during the
time after BEGIN event, one TIMEOUT ever soTimeout
interval. This matches the documentation's description of
timeout semantics. However, I have observed empirically
that if an attempt is made to send data back to the client
(via Response.outputStream.write/flush), no data is actually
sent on the wire IF the write is done AFTER one of these
timeout events has arrived. That is, if I change the timeout
such that it is longer than the time at which the application
responds to the client, the client receives the data. If I make
the timeout shorted, the client does not receive the data.
There is no exception thrown, and in fact I've single stepped
into the NIO code all the way to the socket write and flush
calls. Everything looks ok, but no data makes it to the wire
(confirmed in a packet trace).

So, I'm wondering: is this expected behavior ? If so
then the documentation is incorrect. Also, if this is
the intended behavior it would appear to make it hard
to build a working application for APR because the
timeout can't be set after connection establishment
(the same timeout, it appears applies to all socket reads,
and hence setting it to a very long time will cause thread pool starvation trouble with
new connections that stall with the client never sending any data).

Any thoughts on this are most welcome.






---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to