On Oct 12, 2012, at 10:28 PM, Santiago Pericas-Geertsen wrote:
>
> 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/container/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.
Understood. And the new async allows the client to open it again immediately after an event.
I never looked at Comet architectures, hence I was wondering whether this is the essence of them.
(Though all pointers suggest Comet is just a name for long lived requests - but that has been
around since the elder days)
> The resume method can only be called once on a connection, so this isn't designed for HTTP streaming.
>
I guess we wouldn't want to embedd an async server into one thread of an otherwise synchronous architecture (EE containers).
(But I am really just exploring what the new API is good for now ... and in 3.0 maybe).
Jan
> -- 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
>>>>>
>>>>>
>>>
>>>
>>
>