200 OK is immediate, but the body is left open. meaning, the chunk is left.
you can share your tcpdump and tomcat logs
Filip
On 11/10/2009 07:08 AM, georgi danov wrote:
Hi,
I have a CometProcessor servlet that receives events and queues them for
processing by separate thread pool (a.k.a. asynchronous processor). I do
that because I could get 1000s of concurrent requests for job that includes
IO wait and I don¹t want to have 1000s of threads lying around waiting for
IO. My IO signals me when the response is ready, so I pull the respective
CometEvent instance, write to the reply and gracefully close the message.
I¹ve read number of documents and posts on this mail list and I think I
am doing the things correctly, however 1 out of 500 messages gives me
problem.
The problem is that the client immediately gets HTTP 200 reply with empty
body from the server without my application having a chance to write to the
outputStream. This happens both using the NIO and the regular (with ARP)
connectors. Both using persistent and non-persistent connections. When
looking at tcp dump I see that the response is given practically
immediately. Setting the event timeout to 1 sec does not help.
I can see also that the client is behaving well, because when I use
persistent connection, the conversation goes on after the faulty message
and the next messages are OK.
I am pretty sure I am doing something wrong with handling the cometevent,
but not sure where to start. For one thing I am confused where and when
should the event.close() invocation be I've seen on this mailing list
both the advice to put it in the end event handling and right after I finish
writing to the stream.
Thanks
Georgi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
