Return-Path: X-Original-To: apmail-cxf-dev-archive@www.apache.org Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E1E709C1F for ; Thu, 29 Mar 2012 19:07:03 +0000 (UTC) Received: (qmail 81465 invoked by uid 500); 29 Mar 2012 19:07:03 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 81427 invoked by uid 500); 29 Mar 2012 19:07:03 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 81417 invoked by uid 99); 29 Mar 2012 19:07:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Mar 2012 19:07:03 +0000 X-ASF-Spam-Status: No, hits=2.0 required=5.0 tests=SPF_NEUTRAL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [64.85.173.253] (HELO server.dankulp.com) (64.85.173.253) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Mar 2012 19:06:57 +0000 Received: by server.dankulp.com (Postfix, from userid 5000) id 15596182A7D; Thu, 29 Mar 2012 15:06:35 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on server.dankulp.com X-Spam-Level: X-Msg-File: /tmp/mailfilter-dev@cxf.apache.org.OU2cBZMS6H Received: from dilbert.dankulp.com (c-24-91-72-253.hsd1.ma.comcast.net [24.91.72.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.dankulp.com (Postfix) with ESMTPSA id D2113182A7D; Thu, 29 Mar 2012 15:06:34 -0400 (EDT) From: Daniel Kulp To: dev@cxf.apache.org Cc: Seumas Soltysik Subject: Re: Minimizing thread usage for asynchronous invocations Date: Thu, 29 Mar 2012 15:06:32 -0400 Message-ID: <4471495.c3OPPc4ro9@dilbert.dankulp.com> User-Agent: KMail/4.8.0 (Linux/3.2.2; KDE/4.8.1; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Old-Spam-Status: No, score=-102.9 required=3.0 tests=ALL_TRUSTED,BAYES_00, SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.3.2 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: > http://cxf.547215.n5.nabble.com/Async-HTTP-client-side-td2835428.html Never had time to really finish/pursue that more in depth. :-( -- Daniel Kulp dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com