Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 46348 invoked from network); 12 Oct 2010 23:42:47 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 12 Oct 2010 23:42:47 -0000 Received: (qmail 21052 invoked by uid 500); 12 Oct 2010 23:42:46 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 20968 invoked by uid 500); 12 Oct 2010 23:42:46 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 20960 invoked by uid 99); 12 Oct 2010 23:42:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Oct 2010 23:42:46 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,SPF_HELO_PASS,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jak-commons-dev@m.gmane.org designates 80.91.229.12 as permitted sender) Received: from [80.91.229.12] (HELO lo.gmane.org) (80.91.229.12) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Oct 2010 23:42:39 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P5oU2-0001b0-5n for dev@commons.apache.org; Wed, 13 Oct 2010 01:42:14 +0200 Received: from hsi-kbw-078-042-101-027.hsi3.kabel-badenwuerttemberg.de ([78.42.101.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Oct 2010 01:42:14 +0200 Received: from joerg.schaible by hsi-kbw-078-042-101-027.hsi3.kabel-badenwuerttemberg.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Oct 2010 01:42:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: dev@commons.apache.org To: dev@commons.apache.org From: =?UTF-8?B?SsO2cmc=?= Schaible Subject: Re: [pool] runtime re-configuration Followup-To: gmane.comp.jakarta.commons.devel Date: Wed, 13 Oct 2010 01:42:05 +0200 Lines: 27 Message-ID: References: <4CB478D7.8090106@gmail.com> <5884F60A-6136-4832-BABC-80065D5258D1@seagullsoftware.com> Reply-To: joerg.schaible@gmx.de Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: hsi-kbw-078-042-101-027.hsi3.kabel-badenwuerttemberg.de Mail-Copies-To: nobody User-Agent: KNode/4.4.5 X-Virus-Checked: Checked by ClamAV on apache.org Gary Gregory wrote: > I too would like to be able to tweak the size of the pool at runtime. > > Gary > > On Oct 12, 2010, at 13:19, "James Carman" > wrote: > >> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi >> wrote: >>> Hi Phil! :) >>> honestly I didn't understand which are the use cases when a pool needs >>> to be reconfigured, that's why I've always used the pool in "configure >>> and use" modality and Seb's suggestion sounded good to me. OTOH I >>> didn't modify any single code line before hearing your thoughts since >>> you know much more than me. >>> If pool's property are mutable, so I need to add the setters, make >>> them final otherwise :P >> >> What if you want to alter the way the pool works at runtime? Perhaps >> you're seeing that it keeps causing long waits because you're not >> allowing it to grow big enough? Why then not create a new pool and take over ownership of the objects? - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org