I would suggest checking out CDI's event mechanism first.
On 8/1/11 2:12 PM, Markus KARG wrote:
> Bill,
>
> it's not thought to the end, but here is how to handle external events using
> my proposal. Don't treat it like real syntax, it just shall make clear the
> core idea. Again, what I pretend is not that exact technical solution but I
> want to get rid of a lot of new annotations and possibly no needed
> complexity of the original proposal.
>
> @Inject @Named("MyExternalEventSource") ES es; // CDI manages a named event
> source accessible by MDB etc.
>
> @GET @Async("MyExternalEventSource") MyUserDefinedEvent get() {
> return new MyUserDefinedEvent(es);
> }
>
> What this does is sketched here:
>
> Container calls es.addEventListener(...get()...); --> Done for now, thread
> is free to do other things.
>
> External event happens (e. g. MDB was triggered) --> MDB calls
> es.fireEvent(Object) --> Callback calls get() --> returns
> MyUserDefinedEvent.
>
> (hope the scheme is clear, have no time to write more currently)
>
> The only thing I don't like with that sketch is that ES must be a JAX-RS
> defined type but as this proposal is much simpler to understand than the
> original one (at least for me) I rather would live with that than having to
> deal with more JAX-RS specials.
>
> Regards
> Markus
>
>> -----Original Message-----
>> From: Bill Burke [mailto:bburke_at_redhat.com]
>> Sent: Montag, 1. August 2011 19:33
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Subject: [jsr339-experts] Re: Simplified Async Proposal
>>
>> 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
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com