tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Praveen Balaji <pba...@yahoo.com>
Subject Re: Comet and Async Servlets - Architecture Question
Date Thu, 03 May 2007 04:32:36 GMT


Thanks Sebastiaan. I came to about the same conclusions
as you listed out here. I also saw your post on parsing POST parameters and I think
it's going to create problems for me as well!


 


I am unsure the API would be "improved". I
simply think, as Filip pointed out earlier, what we want to use is Async
servlets and Comet is not intended to solve the same problem.



Let's see what I can come up with!

Praveen

----- Original Message ----
From: Sebastiaan van Erk <sebster@sebster.com>
To: Tomcat Users List <users@tomcat.apache.org>
Sent: Wednesday, May 2, 2007 11:19:29 AM
Subject: Re: Comet and Async Servlets - Architecture Question

Praveen Balaji wrote:
> The
> last few days I have been evaluating using CometProcessor to work like an
> Async Servlet for me. I pick up the CometEvent object on BEGIN event and
> process the whole request asynchronously. When I am done, I close the I/O stream.
>  
>
> I
> would like to know what the Tomcat developers and the developers in general
> think about this approach. Is it a misuse of the API to process requests
> asynchronously, outside of the event method? Are there any issues that I should be cautious
about? Synchronization issues?
>
>
>   
See the mailing list archive of the last month and filter on "comet". 
There have been quite a few posts on exactly this subject.

There are multiple issues:

1) Closing the I/O stream (on the response) does not end the 
request/response. It takes another 30-60 seconds before the event method 
gets called with an END event leaving a lot of request open unnecessarily.

2) Nothing is synchronized in Comet, so you have to do all 
synchronization yourself. You have to make sure that you do not write to 
the output stream after the event is closed (even though you may still 
have the reference in your asynchronous application code). I seem to 
have eliminated most issues by synchronizing access to the response 
output stream and using the same lock around the event.close() method in 
the event() method of the CometProcessor. However I still very 
sporadically get a ClientAbortException/ClosedChannelException which 
suggests that I've missed a place where synchronization is necessary. It 
might not be possible to synchronize this though, because it could 
happen deep inside Tomcat. The API has no information about what to 
synchronize for asynchronous use.

3) If you rely on the POST method to send parameters to your 
CometProcessor, then you have to parse the parameters yourself; there is 
an issue that doing getParameter() on the request in the BEGIN event may 
return null because the request body has not yet been received by the 
server at the moment of the getParameter() call.

One of the Comet developers (Remy) suggests that it might be better to 
just use normal servlets and buy some extra memory for the extra threads.

As far as the current API goes, I would say it is probably a "misuse", 
though I would very much like to see the API improved so that this is no 
longer the case.

Regards,
Sebastiaan

> Thanks,
> Praveen Balaji.
>   
>  
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>   

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org







__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message