Bill,
I doubt that I have more experience (in the sense of empiric learning). I
only concluded from what I remember of the networking tracks at College,
reading the http specs and Fielding's thesis, and from dicussions with
Fielding and the vendors of SQUID (which is applied by lots of service
providers, but has only limited http/1.1 support). So it's more a
"meta-experience". ;-)
In fact, as soon as COMET has to work via the www, it actually *is* as
unefficient as iterative long-pooling using vanilla http -- since it *is*
exactly that. The reason is that http/1.0 (which closes TCP connect after
http response) is not officially obsoleted (even after years of http/1.1 on
the road now; and by good intention, as the www would break otherwise), so
any proxy between the browser and the server (e. g. security appliances
installed by local administrators, edge side caches used by the access
provider to reduce traffic, DoS-blockers and content offloaders - like
SQUID) can close the connection (and is likely to do this since a typically
rather underpowered security applicance typically will have no interest in
keeping open lots of TCP streams just because some client asks to do so).
When using COMET within the company's domain, things certainly are much more
relaxed as the administrators can supply a persistent-connection-friendly
infrastructure as they have an end-to-end view of the http connection (what
using the www as a transparent intermediary foils). Certainly in that
scenario (and I assume many JAX-RS users live within such a scenario) COMET
via Keep-Alive is much more efficient as the TCP-connection-overhead is
completely stripped.
The problem is that an ISV does not know whether or not his software will be
used with an http/1.0 intermediate. So he *must* implement long-term
polling, and as he is not paying for the traffic of his users, *his* will to
add COMET-via-Keep-Alive ontop of the already implemented long-term polling
is near to zero. A solution would be to modify the JAX-RS spec in a way that
enforces the JAX-RS client and server implementation to automatically
support both COMET styles. Declaring the result as StreamingOutput is only
half the rent, as the spec does not mandate that the Keep-Alive header is to
be sent by the client / to be respected by the server, StreamingOutput must
survive http-reconnects (for http/1.1 servers being compatible to http/1.0
clients), or that InvocationCallback<?> MUST be invoked once for each server
side event (the spec can be interpreted as if it will invoke the callback
only once the request is done, not once for each event transmitted via a
http/1.1 connection).
So Jan's questions might be a trigger for a spec improvement?
Regards
Markus
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Samstag, 13. Oktober 2012 12:37
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: How are suspended responses usually
> managed?
>
>
>
> On 10/12/2012 4:39 PM, Markus KARG wrote:
> > Yes this is one form of COMET. And: No, typically the browser will
> not
> > keep the connection open, since this only works if a really lot of
> > constraints
> > *all* are fulfilled:
> > - The browser, the server, and all intermediate proxies must be
> > http/1.1 compliant AND implement the persistent connection feature
> > (which is optional even in http/1.1), and all these systems must be
> bug-free.
> > - The browser, the server, and all intermediate proxies must intend
> to
> > actually use the persistent connection feature, as even a http/1.1
> > compliant party that fulfils the above constraints in some situations
> > might intentionally prefer not to keep the connection open but
> instead
> > close it temporarily and restart another connection later (e. g. if
> > the traffic on the party is rather high, but the traffic on that push
> > line is rather low), which is a valid implementation of http, unless
> > http/1.0 will be officially "forbidden" (which typically will never
> happen).
> > - All of the participating parties must do both above issues at the
> > same time. If only one constraint is not fulfilled at any time, the
> > connection cannot kept open.
> >
> > Example: You did your best efforts but for offloading reasons a Squid
> > 3 proxy is installed -- which does not implement http/1.1 completely
> > and chances are high that it has lots of bugs... which foils the
> > browser's and server's best efforts.
> >
> > You see, chances are very low that the connection actually is left
> > open (unfortunately).
> >
>
> Sounds like you have a *lot* more experience than me with this, but, I
> still find it hard to believe that the connection is closed so often.
> If this is true, then COMET style apps really aren't much more
> performing than vanilla HTTP.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com