users@jersey.java.net

Re: Comet and Jersey

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Thu, 17 Apr 2008 14:14:32 -0400

Hi Paul,

Paul Sandoz wrote:
> Salut Jean Francois,
>
> Thanks for committing Comet prototype stuff we worked on.

Agree, it is nice to see the famous chat examples running on Jersey :-)

  I think we can
> do a lot of nice stuff at the level of the application programming model.
>
> From what we did these might be the core Jersey runtime requirements:
>
> 1) The Grizzly response adapter when using comet should not close the
> grizzly output stream.
> Maybe it makes sense when Grizzly is configured for comet that it
> ignores the close on a GrizzlyResponse.getOutputStream().close(), or
> is that still required? If so Jersey needs to determine if Comet is
> enabled or not.

I think Jersey needs to know if Comet is enabled or not as some requests
might needs to be committed (like a GET).

For now we have focussed on Grizzly, but it should be easy to extend our
work to use Jetty or Tomcat. So we should try to come with a generic
approach.


>
> 2) We need a way to easily re-write headers and entities on the
> long-lived HTTP response context for pushing information.
> Currently i think we hacked something together but we may be able to
> expose a method:
>
> HttpResponseContext.push(Response r)
>
> that will write the status headers (if any) and entity (if any) and
> has different semantics to HttpResponseContext.setResponse.
> Such a method can throw UnsupportedOperation exception if not
> implemented by certain containers or if called in non-push scenarios.

+1


>
> 3) As i understand it the Comet GET method will pass the resource
> instance to a created Comet handler and the Comet PUSH method will
> get invoked later on that same instance.

That's the recommended way. Comet is fairly new, but usually you use a
GET to tell the container to suspend the connection and wait for server
events (push). Now we might think about supporting POST as well, as some
Comet application might use POSTs all over the place


>
> For per-request resources the Comet GET will result in a new instance
> of the resource class. We should ensure that the Comet PUSH does not
> result in reentrant calls to Comet PUSH method as it will break the
> life-cycle contract.
>
> For singleton resources all such methods can be reentrant. Thus we
> could choose to enable reentrant push on such configured resource
> classes.
>
> If we want to support reentrant PUSH on per-request life-cycle then
> the Comet GET method needs to return the notifying object plus a
> handler for managing the PUSH.

I like the idea :-)

A+

--Jeanfrancois



>
> Paul.
>