users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Re: Remove @ManagedAsync Re: Re: Re: Latest async API changes

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Mon, 13 Aug 2012 15:49:39 -0400

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.

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

-- Santiago