Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-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 5DF103E5B for ; Fri, 6 May 2011 15:25:06 +0000 (UTC) Received: (qmail 38700 invoked by uid 500); 6 May 2011 15:25:05 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 38626 invoked by uid 500); 6 May 2011 15:25:05 -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 38618 invoked by uid 99); 6 May 2011 15:25:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 May 2011 15:25:05 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com designates 209.85.210.43 as permitted sender) Received: from [209.85.210.43] (HELO mail-pz0-f43.google.com) (209.85.210.43) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 May 2011 15:24:58 +0000 Received: by pzk1 with SMTP id 1so1573769pzk.30 for ; Fri, 06 May 2011 08:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=P4kjniDjGQfZMjTBbvwljgVfrTdVXOb1hAWefz5irWQ=; b=P2Nt+A7JDIbGkdcUqMs1AAuu0k6B5ASK8dhPQSGHkzjLZAEIF+I/BR2dSzKBONlWWb 0JSfRCyAT9f9WINfKx/iOKlRTQIvRWz2FDh01f9Vv6ozUqj8vmfCOgIRKo6SH0e231F2 zmx8xZo5aKKZAvEAyGthQnG5z0NyLJxYjcGt8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=FBV1QwfcYgmqxwgOdYR+oYUodlUrMrRttn6EXp0+Yd34fugXsq6yqXuQz+y2p+qV70 Z+AyHNCnyBhH2H8Qdo9KfI+2kni4ZD47mC5PfNzNEc/POKRnzksrq8iL/bhG/4Z6oKR1 eDqr5HaEazZORz/fs83AIHca/y9TL3dtrrREc= Received: by 10.142.119.35 with SMTP id r35mr2004382wfc.411.1304695477711; Fri, 06 May 2011 08:24:37 -0700 (PDT) Received: from a.local (75-171-19-46.phnx.qwest.net [75.171.19.46]) by mx.google.com with ESMTPS id k7sm4281861wfa.14.2011.05.06.08.24.36 (version=SSLv3 cipher=OTHER); Fri, 06 May 2011 08:24:37 -0700 (PDT) Message-ID: <4DC412B3.4060409@gmail.com> Date: Fri, 06 May 2011 08:24:35 -0700 From: Phil Steitz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Commons Developers List Subject: Re: [POOL2] Java 1.5 or 1.6? References: <4DC3D0DD.5080101@apache.org> In-Reply-To: <4DC3D0DD.5080101@apache.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/6/11 3:43 AM, Mark Thomas wrote: > Before I go too far down the road of the re-writing the core object > allocation code for pool2, I'd like to get some clarity on what the > minimum Java version targeted by pool2 should be. It is also logical to ask at this point if the rewrite is desirable / necessary and what we expect to gain from it. I have pretty consistently advocated this, but given the work and inevitable stabilization required, we should at least ask the question. Seems to me the goals should be 0) performance 1) maintainability 2) robustness 3) (configurable?) fairness. Do you agree with these and are you sure the rewrite is necessary to get them? > It is currently 1.5. > > It would make the implementation of the FIFO/LIFO allocation option > considerably easier if that was changed to 1.6. Can you explain a little what the problem is? > The options as I see them are: > > a) Java 1.5 with FIFO or LIFO allocation > b) Java 1.5 with FIFO allocation only > c) Java 1.6 with FIFO or LIFO allocation > > b) & c) are likely to be considerably easier to write since I can use > the classes provided by java.u.c > a) looks like it will be a PITA to write > > My preferred option is c) > > I think b) is a bad idea since it makes idle object expiration harder Right, if there is only one option it should be LIFO (as it was in pool 1.0-1.2). I think configurability is good. > I think a) is a bad idea as I don't want to have to figure out how to > make that work, not do I want to have to maintain it once it is written > as I suspect it will end up being quite complex (although I could be wrong). I share sebb's concerns that this is going to leave some users behind, but they will still have 1.x and it seems a fair expectation that to get the new version they need to 1.6. This is consistent with what we are doing in DBCP. So once I understand what the problem is, I will end up +1 on option c). Phil > Mark > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org