Hi, After some late night debugging yesterday I got it stable. The magic spell was to put event.getHttpServletRequest().setAttribute("org.apache.tomcat.comet.support" , Boolean.TRUE);
in my BEGIN event handler. After that I had to follow the advice to put the event.close() in the END/ERROR handling section, flush regularly and all the strange behaviour I was seeing is gone. Funny enough this is not mentioned anywhere... Something that most probably is important - I am on jboss 4.2.3. Any explanation why I had to put that myself? Filip, I don't have the logs & the dump saved. If you need it, I will reproduce the problem and provide them. Best Regards, Georgi On 11.11.09 08:08, "Filip Hanik - Dev Lists" <devli...@hanik.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org