On 8/14/2012 9:41 AM, Marek Potociar wrote:
> The whole idea behind the annotation was to make application code less
> verbose and life of the JAX-RS developer easier. IOW, instead of
> something like this:
>
> @GET
> @Path("async")
> public void asyncExample(@Suspended final AsyncResponse ar) {
> Executors.newSingleThreadExecutor().submit(new Runnable() {
> @Override
> public void run() {
> // expensive result computation
> ar.resume(result);
> }
> });
> }
>
> the users would be able to write simply this:
>
> @GET
> @Path("async")
> @ManagedAsync
> public void asyncExample(@Suspended final AsyncResponse ar) {
> // expensive result computation
> ar.resume(result);
> }
>
> What's wrong about the code above?
>
What's wrong? It doesn't improve performance! You're just shuffling
work from one thread to another. Async HTTP is for polling protocols
where you don't want a thread consumed by an idle blocking connection.
This is the sole reason the Jetty guys pushed for this feature in
Servlet 3.0.
> Also I quite strongly disagree with your interpretation of asynchronous
> EJB methods being useful just for "fire and forget" operations. Async
> EJBs are in fact primarily used for performing long-running operations
> on a dedicated thread and these operation, one way or the other return a
> result back to the caller (not necessarily on the original thread, of
> course). The async EJB method may either return a Future or, it may
> invoke a callback passed in as one of the arguments.
>
If you read what I wrote, async EJBs are good for *2* things. fire and
forget and operations that run in the background. Operations that run
in the background require a Future interface. Again, if you actually
read what I write...Fire and forget is not possible in HTTP unless you
send back a 202 Accept. REST clients also do not have stubs, so a
Future interface is useless there too. Not to mention that HTTP is
*not* an asynchronous protocol.
The whole point of async EJBs (I actually implemented it back in EJB 3.0
days and had our rep push for it in EJB 3.1), is to free up the client
so that it doesn't have to wait for a long running response. Either the
client just sends the request and is done, or the client sends the
requests, does some other things, then polls the Future when it is ready
to see if the request is done processing. @ManagedAsync *DOES NOTHING*
to free up the client!!!! This is because HTTP is not an asynchrnous
protocol!!!
Sorry if it sounds like I'm yelling, but I just don't know how to get
the point across to you guys.
> Btw. if you still disagree, perhaps you may want to talk to your
> colleagues who wrote the async servlet example for JBoss AS:
> https://github.com/jboss-jdf/jboss-as-quickstart/tree/7.1.2.M1/servlet-async/src/main/java/org/jboss/as/quickstarts/servlet/async
>
Well, I'll have to talk to Pete about remove this example, or at least
changing the wording.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com