You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Praveen Balaji <pb...@yahoo.com> on 2007/05/02 06:24:04 UTC
Comet and Async Servlets - Architecture Question
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?
Thanks,
Praveen Balaji.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Comet and Async Servlets - Architecture Question
Posted by Martin Perez <mp...@gmail.com>.
Sorry about this last email. It was for Sebastiaan but in another thread.
Cheers,
Martin
On 5/2/07, Martin Perez <mp...@gmail.com> wrote:
>
> Sebastiaan,
>
> Yes you're right. I forgot to add something like isClosed() to your
> SynchronizedOutputStream so I can check if it's closed before writing.
>
> Anyways, I found that after a certain limit (for ex. 6000 -> 8000 users)
> the system starts to behave incorrectly. Some clients never get an answer
> from the server, some clients only receive partial data, and some of them
> really end. I guess I found the limit in the box, but attached are the
> source code files if someone wants to see the sample or simply spot
> something in it.
>
> Cheers,
> Martin
>
> On 5/2/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> >
> > 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
> >
> >
>
>
Re: Comet and Async Servlets - Architecture Question
Posted by Martin Perez <mp...@gmail.com>.
Sebastiaan,
Yes you're right. I forgot to add something like isClosed() to your
SynchronizedOutputStream so I can check if it's closed before writing.
Anyways, I found that after a certain limit (for ex. 6000 -> 8000 users) the
system starts to behave incorrectly. Some clients never get an answer from
the server, some clients only receive partial data, and some of them really
end. I guess I found the limit in the box, but attached are the source code
files if someone wants to see the sample or simply spot something in it.
Cheers,
Martin
On 5/2/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>
> 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
>
>
Re: Comet and Async Servlets - Architecture Question
Posted by Sebastiaan van Erk <se...@sebster.com>.
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