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