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" <[email protected]> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]