On Aug 13, 2012, at 11:36 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 8/13/2012 3:49 PM, Santiago Pericas-Geertsen wrote:
>>
>> On Aug 13, 2012, at 10:50 AM, Bill Burke wrote:
>>
>>> On 8/13/2012 10:28 AM, Santiago Pericas-Geertsen wrote:
>>>>
>>>> On Aug 13, 2012, at 10:08 AM, Bill Burke wrote:
>>>>
>>>>>>> Can't you see it is the *SAME EXACT THING* and that there is nothing
>>>>>>> gained here? So instead of configuring and managing just one
>>>>>>> thread pool, you want users to managed and configure 2 thread pools?
>>>>>>> Just doesn't make sense...just add more threads to your servlet
>>>>>>> container's thread pool if CPU is not utilized and you have waiting
>>>>>>> HTTP requests.
>>>>>>
>>>>>> It is and it isn't. Theoretically, yes, practically, no. There are
>>>>>> many other containers that are running and it's just impractical to
>>>>>> let one run over and take all the threads in the system. Once you
>>>>>> partition your system resources (for EJB, JMS, etc) you want to use
>>>>>> the threads for the specific task for which they were allocated. The
>>>>>> problem of configuring multiple thread pools is already present in
>>>>>> any EE installation.
>>>>>>
>>>>>
>>>>> I've run this by numerous people within Red Hat on our web, remoting,
>>>>> messaging, and app server teams. Everybody is unanimous that this is
>>>>> not a useful feature and in fact almost an anti-pattern. You may
>>>>> think you are solving a problem here, but all you are really doing
>>>>> with @ManagedAsync is shuffling request processing from one thread
>>>>> pool, to another.
>>>>
>>>> I understand, it's a difference of opinion and experience I guess.
>>>> IMO, JAX-RS is one of many web technologies and as such should not
>>>> dictate how the web container manages its threads (or how big the thread
>>>> pool is, etc.).
>>>>
>>>
>>>
>>> JAX-RS does not place any restrictions on how the web container manages it threads.
>>
>> Hmmm? I thought you agreed before that you may have to tune the web container thread pool for JAX-RS async in your proposal ... It's really not worth pursing this discussion any further, if it's just the two of us.
>>
>
> I'm saying that the web container or JAX-RS runtime can manage threads however it likes. Not having @ManagedAsync does not restrict this.
I don't see how @ManagedAsync changes that. There is nothing about that annotation that would force you to manage your threads in any specific way. Also, there is no special connection between the annotation and a servlet container in particular. The annotation should work on any JAX-RS enabled container.
>
>>>
>>>> Would you agree to make this feature optional in JAX-RS?
>>>>
>>>
>>> No. I just haven't heard any argument yet that it solves any problem. Except for you and Marek, I haven't talked to one person that agrees its a good idea.
>>
>> OK. Let's hope others can contribute to the discussion.
>>
>
> Yeah, I don't know what else to say to convince you this is a bad feature.
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?
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.
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
Here's also a short section from the example description:
It shows how to detach the execution of a resource intensive task from the request processing thread, so the thread is free to serve other client requests. The resource intensive tasks are executed using a dedicated thread pool and create the client response asynchronously.
Note that the example above does with a raw Servlet + EJB essentially the same thing that the @ManagedAsync is trying to achieve for a JAX-RS resource method. Except that in the example one has to use async Servlet+ async EJB and thus needs to run in a full JavaEE container. Also note that the example demonstrates that there are obviously some other engineers (apart from Santiago and me) who may think that offloading request processing threads is a potentially useful design concept (even in case of a Servlet container that may have it's own dedicated servlet execution thread-pool).
Marek