Your solution doesn't solve the problem. Putting @Async on a method to
tell the server to run it in a thread does nothing but serialize
requests. Same thing with Callable. If you don't want to listen,
that's your prerogative.
EOF
On 8/1/11 1:26 PM, Markus KARG wrote:
> Bill,
>
> I know what it is good for, but my declared intention was to add Pub/Sub,
> Broadcast, Events ontop later actually. Events are just a special case of
> pub/sub with a single subscriber. I thought that it was mentioned clearly in
> the article that the idea is to just define the asynchronous base technology
> and solve everything ontop in a later proposal. I never said the proposal is
> providing all features wanted in this context. In fact I have not even
> thought about the next step but just wanted to make clear that it should be
> much simpler for the programmer to declare his needs, as this discussion
> started with my complaint that the original proposal is looking far too
> complex, remember? My hope was that it there might be a simple way and by
> posting the alternative proposal other experts might see what I want to head
> for and can contribute ideas how pub/sub, broadcast and events can be (maybe
> easily) added. But you are right, if you hoped to get a perfect ready-to-use
> proposal for all async topics, then yes, this is not contained in my
> proposal.
>
> Regards
> Markus
>
>> -----Original Message-----
>> From: Bill Burke [mailto:bburke_at_redhat.com]
>> Sent: Montag, 1. August 2011 13:53
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Subject: [jsr339-experts] Re: Simplified Async Proposal
>>
>> I'm not sure you understand what Async HTTP is for. It is used for
>> Server-side push. In other words, the client does a long poll to the
>> server waiting for the server to be ready to send it an event. i.e. a
>> stock quote update, or a chat message. You want to detach the
>> HttpResponse from a thread so that one server-side thread can dispatch
>> to usually more than one HttpResponse.
>>
>> Your proposal doesn't address this use case at all, IMO.
>>
>> IMO, Async HTTP is way overhyped and we should only offer minimal
>> support for it. It is solely a performance feature that became an
>> issue, IMO, because of the older Linux kernels where threads were so
>> heavyweight. Now this isn't so much an issue with modern kernels and
>> hardware. Other languages, i.e. Erlang, scale better as they
>> automatically suspend threads and do their own internal context
>> switching.
>>
>>
>> We want first and foremost to provide the ability to detach a response
>> from a thread and a mechanism to handle the response asynchronously
>> *however* the application code.
>>
>> Alternatively, we could provide a lightweight message bus, i.e. via the
>> Atmosphere apis, but, IMO, this is a bonus, not a requirement.
>>
>> On 7/30/11 5:16 AM, Markus KARG wrote:
>>> I was asked to put my simplified async proposal in the wiki so
>> experts
>>> can better understand and discuss it.
>>>
>>> So here it is:
>>> http://java.net/projects/jax-rs-spec/pages/SimplifiedAsyncSupport
>>>
>>> Please post comments in this mailing list. :-)
>>>
>>> To sum up a few points from previous discussions:
>>>
>>> * Broadcast and Pub/Sub is not part of the proposal, but should be
>>> simple to implement ontop.
>>>
>>> * No more need for polling or suspending, due to an updated attempt
>>> (using Callable instead of Future).
>>>
>>> * Should be the most simple to learn and apply for programmers, as
>> there
>>> is either nothing to learn (Callable) or just one annotation to add
>>> (@Async).
>>>
>>> * Should be rather easy to implement for JAX-RS implementation
>> vendors,
>>> but opens a lot of possibilities for them like applying work stealing
>> etc).
>>>
>>> -Markus
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com