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 ?
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