You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Benson Margulies <be...@basistech.com> on 2016/03/11 02:52:36 UTC

Performance issues with many outstanding async REST requests

We observe the following:

CXF 3.1.4 in Karaf 4.0.4, with pax web, and thus jetty 9.2.something.

When we have hundreds of outstanding async requests, a thread from
Jetty starts eating CPU time; it uses up an entire core -- it's
spending time in some method of some Eclipse blocking queue class.

1: Has anyone else seen anything like this?

2: We sort of suspect that things might be happier in Jetty 9.3; does
anyone have experience in Karaf of ignoring pax-web and just letting
the CXF http transport grab a port and get busy?

I can supply more details, and I think that I'm doomed to build an
'available on github' test case eventually.

Re: Performance issues with many outstanding async REST requests

Posted by Freeman Fang <fr...@gmail.com>.
Hi Benson,

To ignore the pax-web and spin up a standalone jetty transport, you just need publish the endpoint with absolute url address like http://host:port/context <http://host:port/context>…. with this absolute address the cxf http-jetty transport will kick in but not to use the servlet transport on pax-web.

-------------
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat



> On Mar 11, 2016, at 9:52 AM, Benson Margulies <be...@basistech.com> wrote:
> 
> We observe the following:
> 
> CXF 3.1.4 in Karaf 4.0.4, with pax web, and thus jetty 9.2.something.
> 
> When we have hundreds of outstanding async requests, a thread from
> Jetty starts eating CPU time; it uses up an entire core -- it's
> spending time in some method of some Eclipse blocking queue class.
> 
> 1: Has anyone else seen anything like this?
> 
> 2: We sort of suspect that things might be happier in Jetty 9.3; does
> anyone have experience in Karaf of ignoring pax-web and just letting
> the CXF http transport grab a port and get busy?
> 
> I can supply more details, and I think that I'm doomed to build an
> 'available on github' test case eventually.