tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <>
Subject Re: Ongoing stuff
Date Tue, 16 May 2006 17:30:51 GMT
I think Jetty had an intersting approach on this, with their so called
I didn't like their use of exceptions to control the flow.

+1 on adding the functionality ( as long as you're ok with eventually adding
the same
on the nio connector on sandbox :-), but it would be great to review the
proposed API
that servlets will need to implement.

For example, I would assume what you need is:
1. a servlet to tell tomcat to not close the connection ( "I'm not done, but
I'm going to sleep waiting for events for a while" )
2. a way for a thread/event to tell tomcat to resume a particular request,
3. a way for tomcat to wake up a servlet if some activity happens on the
client side.
For 1 - I assume a tomcat-specific API or (special) request attribute is
needed ( and service() to return ). Jetty uses a
special exception, I don't think it's a good idea.
For 2 - any reason for new API ? Could it just use the saved response object
For 3 - ??? Call service again with an extra attribute ?  Require servlets
to implement an interface or to
register with tomcat a callback ( maybe using setAttribute when going to
sleep ) ?


On 5/16/06, Remy Maucherat <> wrote:
> Costin Manolache wrote:
> > For those of us who don't know much about 'comet' - could you explain a
> bit
> > more ?
> > A small example, some pointers to what APIs are needed ( if it's not
> > service
> > ),
> > why service doesn't work, etc.
> There's some documentation here:
> The (only) actually useful capability is of course to push back data at
> any time. To replicate the same with regular servlets, you need a
> forever running service method, which doesn't work that well. It's
> really evil-hype-powered stuff, and I think it's all your company's fault
> :(
> However, since my attempts at SIP (which has the same biderectional
> capabilities without the hacks, of course) miserably failed, and since
> it's not too hard to implement in the APR connectors, I think it should
> be done (the API right now is an interface that the servlet should
> implement, but I plan to provide a ready to use abstract servlet which
> should be easy to work with).
> Rémy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message