cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Seumas Soltysik <>
Subject Re: Minimizing thread usage for asynchronous invocations
Date Fri, 11 May 2012 06:02:54 GMT
Hi Dan,
I think I found the source of the issue.

The customer I have been working with noted that for async call, CXF 2.1.x
was behaving differently that CXF 2..3.x.
In 2.1.x the number of threads being created to handle the response for
async call was limited by the parameters of the AutomaticWorkQueue. The
result was that 100 async calls would only produce a maximum of 25 threads
to handle the responses to the calls.

Howerver, the customer noticed that for 2.3.x for 100 async invocations,
100 threads were being created to handle the responses.

By comparing the HTTPConduit code for 2.1 to 2.3, I was able to find the

Here is the pertinent code for 2.1:

                WorkQueueManager mgr =
                AutomaticWorkQueue queue =
                if (queue == null) {
                    queue = mgr.getAutomaticWorkQueue();

Here is the code for 2.3:

                    Executor ex =
                    if (ex == null) {
                        WorkQueueManager mgr =
                        AutomaticWorkQueue qu =
                        if (qu == null) {
                            qu = mgr.getAutomaticWorkQueue();
                        qu.execute(runnable, 5000);
                    } else {

                                                 + ".USING_SPECIFIED",

As you may notice the major difference is that the first step in the 2.3
 code is to get an Executor from the Exchange.

For async calls the Executor is not null. The Executor is set in the
ServiceImpl.createPort() code:

        service.setExecutor(new Executor() {

            public void execute(Runnable command) {

                Executor ex = getExecutor();

                if (ex == null) {

                    ex = OneShotAsyncExecutor.getInstance();





The OneShotAsyncExecutor does not throttle the thread creation which
results in the issue mentioned above.

By adding code like this after the creation of the proxy, the old behavior
is established:

rpcperf = aRPCPerfService.getRPCPerfSoapHttpPort();

Bus bus = BusFactory.getDefaultBus();

WorkQueueManager mgr = bus.getExtension(WorkQueueManager.class);

Executor ex = mgr.getAutomaticWorkQueue();

org.apache.cxf.endpoint.Client client =

org.apache.cxf.endpoint.Endpoint cxfEndpoint = client.getEndpoint();


Not sure what the exact fix is for this since adding the check for the
Executor on the service seems like it might be important for setting custom

By inspection, this seems to be a problem on trunk as well.



The problem is that for async calls, this is not null by default.

On Thu, Mar 29, 2012 at 3:06 PM, Daniel Kulp <> wrote:

> On Thursday, March 29, 2012 02:36:55 PM Seumas Soltysik wrote:
> > It would appear at this point that each async invocation involves a
> > listener thread, waiting for a response from the server. Is there a way
> to
> > configure the number of listener threads used by a particular client so
> > that 100 async invocations do not result in 100 listener threads?
> The default should max out at 25 per bus.   Basically, they end up on the
> "default" WorkQueue of the bus which default to a max of 25 threads.   You
> can configure the default WorkQueue to have more or less threads if you
> want.
> There is supposed to be code to allow for a specific "http-conduit" named
> workqueue to be optionally configured, but I just noticed that code isn't
> working properly and will always re-grab the default workqueue.  I'll get
> that fixed.
> You can also call the Service.setExecutor(..) prior to creating the proxy
> if
> you want to specify a specify executor for the client.
> > I was doing some research on this issue and it appears that at some point
> > there was some work being done in this area:
> >
> Never had time to really finish/pursue that more in depth.   :-(
> --
> Daniel Kulp
> -
> Talend Community Coder -

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message