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

Reply via email to