Well, you can't stream, but you can still long-poll, which should be
sufficient for low- to mid-frequent message intervals.
> -----Original Message-----
> From: Santiago Pericas-Geertsen
> [mailto:Santiago.PericasGeertsen_at_oracle.com]
> Sent: Freitag, 12. Oktober 2012 22:28
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: How are suspended responses usually
> managed?
>
>
> On Oct 12, 2012, at 4:10 PM, Jan Algermissen wrote:
>
> >
> > On Oct 12, 2012, at 9:54 PM, Markus KARG wrote:
> >
> >> I'm rather sure you'll be very pleased by having a look at
> >> AsyncResponse's JavaDocs (the code example in the class docs showing
> >> how to implement COMET "pushing")... ;-)
> >
> > You mean the intro of
> >
> > http://jax-rs-spec.java.net/nonav/2.0-
> SNAPSHOT/apidocs/javax/ws/rs/con
> > tainer/AsyncResponse.html
> >
> > Is that Comet? Would the browser open a new connection after
> receiving the push?
>
> The message reader would need a connection per message. The resume
> method can only be called once on a connection, so this isn't designed
> for HTTP streaming.
>
> -- Santiago
>
> >>
> >>> -----Original Message-----
> >>> From: Jan Algermissen [mailto:jan.algermissen_at_nordsc.com]
> >>> Sent: Freitag, 12. Oktober 2012 21:37
> >>> To: jsr339-experts_at_jax-rs-spec.java.net
> >>> Subject: [jsr339-experts] Re: How are suspended responses usually
> >>> managed?
> >>>
> >>>
> >>> On Oct 12, 2012, at 9:28 PM, Markus KARG wrote:
> >>>
> >>>> Jan,
> >>>>
> >>>> just scanned the public draft of the spec and did not find the
> word
> >>>> "push" a single time! How did you come to the conclusion that the
> >>>> async API will allow you to implement frequent server pushes ontop
> >>>> of
> >>> it?
> >>>
> >>> I thought that was one of the motivations behind it and Bill
> >>> mentions it as one in his Oct 9th talk on Infoq.
> >>>
> >>>
> >>>
> >>> Jan
> >>>
> >>>
> >>>>
> >>>> Regards
> >>>> Markus
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Jan Algermissen [mailto:jan.algermissen_at_nordsc.com]
> >>>>> Sent: Freitag, 12. Oktober 2012 16:11
> >>>>> To: jsr339-experts_at_jax-rs-spec.java.net
> >>>>> Subject: [jsr339-experts] Re: How are suspended responses usually
> >>>>> managed?
> >>>>>
> >>>>>
> >>>>> On Oct 12, 2012, at 3:49 PM, Bill Burke wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 10/12/2012 9:38 AM, Jan Algermissen wrote:
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> when a response is suspended by the async API the request
> >>>>>>> handing
> >>>>> thread is being 'released from duty' and can continue serving
> >>> requests.
> >>>>>>>
> >>>>>>> So far I understand. What I am not entirely clear about is what
> >>>>> happens with the suspended response - will these be 'parked' in
> an
> >>>>> extra thread? Or will there be one thread for each suspended
> >>> response?
> >>>>>>>
> >>>>>>
> >>>>>> Its up to you and your application. That's the idea.
> >>>>>
> >>>>> Ok, yes.
> >>>>>
> >>>>> Sorry for being stupid.. but:
> >>>>>
> >>>>> - so when I suspend a response without invoking a new thread
> >>>>> nothing happens except that a connection is being used (meaning
> >>>>> that a
> >>> queue
> >>>>> of 1000 responses would use up 1000
> >>>>> connections)
> >>>>>
> >>>>> - when I resume the response, the response will be sent in the
> >>>>> current thread of execution.
> >>>>>
> >>>>> That's simple, but I find the implications not so easy to see at
> >>> first.
> >>>>> Thanks.
> >>>>>
> >>>>>
> >>>>> What I would love to be able to do is to suspend/resume again.
> >>>>> Considering server push, it seems odd that I can have a long
> >>>>> running request without resource consumption *until* the first
> >>>>> bits of the response are sent. What if I want to send one event
> every Minute?
> >>> The
> >>>>> initial async doesn't really buy me that much, does it?
> >>>>>
> >>>>> (just trying to get my head straight)
> >>>>>
> >>>>> Jan
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Bill Burke
> >>>>>> JBoss, a division of Red Hat
> >>>>>> http://bill.burkecentral.com
> >>>>
> >>>>
> >>
> >>
> >