On 8/13/2012 9:39 AM, Santiago Pericas-Geertsen wrote:
>
> On Aug 10, 2012, at 1:41 PM, Bill Burke wrote:
>
>>
>>
>> On 8/10/2012 11:43 AM, Santiago Pericas-Geertsen wrote:
>>>
>>> On Aug 10, 2012, at 11:14 AM, Bill Burke wrote:
>>>> On 8/9/2012 5:55 PM, Santiago Pericas-Geertsen wrote:
>>>>>
>>>>> On Aug 9, 2012, at 2:49 PM, Bill Burke wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 8/9/2012 12:06 PM, Marek Potociar wrote:
>>>>>>>> On 8/8/2012 3:06 PM, Bill Burke wrote:
>>>>>>>>> I don't agree with @ManagedAsync. A method annotated with @ManagedAsync
>>>>>>>>> is executed in a separate thread? The servlet container is *already*
>>>>>>>>> doing this so I don't see the point of this annotation.
>>>>>>>
>>>>>>> Apart from the fact that JAX-RS is not bound to run just on a servlet container, I believe you're also wrong when it comes to the assumption that a servlet is executed on a separate thread from the one that received the client connection. Servlet is (or at least can be) executed by exactly the same thread that received the client connection. (Because unless your servlet is async-dispatched, the client connection will close once the call to the servlet method terminates. IOW, async Servlet dispatching is not about async execution, it is about telling the Servlet container that it should not automatically close the client connection when the servlet call returns.) As you know the pool of these connection-handling threads is typically limited. And even if the servlet container had a special servlet execution thread pool, that pool would also be typically limited. Look at any async Servlet example - the request is either dispatched to a different servlet (with a possible!
s!
>> pe!
>>>> ci!
>>>>>>>
>>>>>>
>>>>>> The performance benefit of @ManagedAsync is questionable because most production quality servlet containers know how to manage lots of concurrent connections very well. In fact, in most cases, using a completely separate thread to just marshall and send back the response on the wire would be detrimental to performance as it would involve context switching.
>>>>>
>>>>> I guess this depends a lot on the container's architecture. Sometimes, there's a max number of request threads configured in the container and you don't want to tie up one of those on a long running operation to avoid a denial of service.
>>>>>
>>>>
>>>> I really don't think there is any gain by doing this. It's still a thread per connection to matter how you look at it. While you're not consuming a thread of the servlet container, you're consuming a thread of some other executor. You are just not doing anything new that the servlet container isn't already doing for you!
>>>
>>> Does your servlet container use an unbounded thread pool? If so, there won't be much difference. However, most servlet containers use a bounded thread pool. If that bound is reached and the CPU utilization is not maxed out, then using other threads will increase throughput as more connections will be accepted.
>>>
>>
>> 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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com