Agreed. Just wanted to explain why Marek tends to name it "wrong".
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Freitag, 9. November 2012 19:45
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Overhead of
> AsyncResponse
>
> 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