users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Overhead of AsyncResponse

From: Bill Burke <bburke_at_redhat.com>
Date: Thu, 08 Nov 2012 19:50:25 -0500

On 11/8/2012 1:39 PM, Markus KARG wrote:
>>> @Bill, why do you think your's is 'better' than handing the long
>> running task to another thread, especially one from a different thread
>> pool?
>>>
>>
>> I don't have a problem with saying this is 'better' or not. I do have
>> a problem with saying that this is wrong, because its not. Defining
>> and configuring multiple thread pools can be a burden on both the admin
>> and developer, not to mention the extra code the developer has to
>> write.
>
> But Bill, only if the programmer puts the burden into a second thread pool,
> the administrator can adjust the behaviour of the container by tuning the
> pools differently.

In my experience, admins want *less* things to configure, not *more*.

> If instead the programmer follows your pattern, the
> administrator has no chance for tuning, as the container does not "see" the
> different work types of protocol level processing (hence blocking LAN ports)
> and application level processing (hence blocking CPU cores). So I have to
> say that it is always correct to do it in Marek's way as it opens this
> possibilities of performance tuning, resource cab and division of labour,
> while it could become (at least) problematic to do it in your way (unless in
> a DevOps scenario).
>

This is typical big-vendor way of designing systems. Bring in as much
infrastructure as possible "just in case". Majority of apps don't
require async hTTP, nor do they have the load that would trigger these
nightmare load scenarios, but, they might want a way to easily let the
client continue while the server does some work. Same reasons why
somebody might want to use a POJO instead of an EJB,
java.util.concurrent.Queue instead of JMS, servlet instead of JAX-RS :)


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com