On Aug 15, 2012, at 11:33 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> Hi
> On 14/08/12 16:41, Marek Potociar wrote:
>>
>> On Aug 13, 2012, at 11:36 PM, Bill Burke <bburke_at_redhat.com
>> <mailto: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?
>>
>
> Can we get both approaches working ?
Sure - that's the point - if you want to manage threads yourself, do it. If you don't let JAX-RS runtime do it for you.
Marek
>
> Cheers, Sergey
>
>> 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
>
>