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