I'll reiterate. If you want to argue on what is better and what isn't.
I'm fine with that. There is not a wrong or right here, IMO.
On 11/9/2012 12:56 PM, Markus KARG wrote:
> Have to object: Our world wide 260+ "enterprise grade" customers really love
> tuning options, since about 10% of them sooner or later had experienced
> problems as those described. :-)
>
> I really understand you point of view, but JAX-RS is planned to be part of
> Java EE ("Enterprise", not "Embedded") so it should target _more_ on
> enterprise needs than on SOHO needs (I would agree to your good points if
> JAX-RS would be planned to be part of Java SE, what actually would be rather
> cool). As an ISV, I do not know at time of boxing whether my customer in
> future is driving a server farm or a laptop-as-a-server, so I have to
> prepare my application for the largest possible scenario (or clearly tell
> customers: Do not use in heavy-duty-environments -- which would cut revenue
> from those 260+ companies!).
>
> There is nothing lost if one adds Marek's kind of "complex" support, it is
> rather unexpensive to implement. But there could be a problem if we omit
> this support. Call that "overload-angst" a vendor-view if you like, but as
> soon as your customer has to span half of the world with his server farm,
> this soon becomes a customer-view, too. ;-)
>
>> -----Original Message-----
>> From: Bill Burke [mailto:bburke_at_redhat.com]
>> Sent: Freitag, 9. November 2012 01:50
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Overhead of
>> AsyncResponse
>>
>>
>>
>> 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
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com