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.).
Would you agree to make this feature optional in JAX-RS?
-- Santiago