Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.210.43 as permitted sender)
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=xmtnOrY9fGBbRpYsPJFOtpjlPD9rCy1x29ehIK6w7dYydGEBuB5M2FJ1YI/JCSSo7N
         0b+SG46TUyRAEeTlnXGfoVYS0aSd6lm0bMdiLyI+ktU/QycoYQVwUYfbQjoy0bhYf7QE
         Grf/3gDQIZPk4O4PZ8GpGnUjtURZ75ceauPEU=
Message-ID: <4DC432FC.6040909@gmail.com>
Date: Fri, 06 May 2011 10:42:20 -0700
From: Phil Steitz <phil.steitz@gmail.com>
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 <dev@commons.apache.org>
Subject: Re: [POOL2] Java 1.5 or 1.6?
References: <4DC3D0DD.5080101@apache.org>	<4DC412B3.4060409@gmail.com>
	<4DC4153F.1040303@apache.org>
	<BANLkTinnLAgQWg62ZTjWUfcUEn4vSatyTQ@mail.gmail.com>
	<BANLkTi=3u9Q8uL8_knTAnF1RKdXkGfNYEA@mail.gmail.com>
	<4DC41EBF.5090409@gmail.com>
 <BANLkTi=PehBsQ9hijiH=uUpH-XgPnABCKg@mail.gmail.com>
In-Reply-To: <BANLkTi=PehBsQ9hijiH=uUpH-XgPnABCKg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 5/6/11 9:29 AM, Simone Tripodi wrote:
> Hi Phil,
> thanks for taking in consideration my thought! I wouldn't maintain 3
> version either, anyway we could "evolve" the actual Pool2
> implementation into the one described in the roadmap - that I
> perfectly agree and like, no objections there! - little step by little
> step, releasing early and often intermediate versions.

Again, i appreciate the sentiment here and would under normal
circumstances support it; but in this case you do in fact end up
having to support three different versions if you go down this path
and actually release a pool 2 based on the 1.x code (with 1.5
required JDK) and then pool 3 with rewritten internals and
refactored API (and 1.6+ JDK).   Once you have released the 2.0
version based on the 1.x internals and API, you are signing up to
support both of them.  That is what I want to avoid.   As I said in
another post, "release early, release often" is challenged in this
case for two reasons:

1) major, incompatible releases of widely reused library components
cannot be "often" - so the "often" part needs to be punctuated by
runups to major releases
2) pool sits at the core of many server applications and at a low
level in the dependency hierarchy, so "early" badly bugged releases
can wreak havoc once they get into the food chain.

Item 2) above can be handled by aggressive patching / release
classification, etc.; but it underscores the point that whatever we
release in [pool] we need to be prepared to support with patch
releases.  So the 1.x, 2.x, 3.x story is unavoidable unless we merge
2.x with 3.x (or logically, merge 2.x into 1.x; but I don't see a
way to do that without breaking compatibility).

> In that way, users with OSs that don't support JVM6 yet, still have
> the opportunity to update pool library without having the need of
> upgrading the whole platform.

I understand, but just don't see a practical way to do it.  As we
dig into the 2.0 code, it could be Mark's initial analysis is
revised and we find a way to make things work for both.

> By the way, even if looks like I'm a part of minority, I'll respect
> the decision you'll made and won't oppose any veto, and continue
> contributing.

Thanks!

Phil


> Have a nice day, all the best,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, May 6, 2011 at 6:15 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
>> On 5/6/11 8:57 AM, Simone Tripodi wrote:
>>> Honestly, I agree with Paul. Let's release early and often!
>> I understand the sentiment here, but I do not think it is practical
>> or advisable.  If you look deeply into the current [pool] code and
>> the history of bugs that we have had to deal with, you will see that
>> maintaining three versions of pool concurrently is a bad idea.  We
>> simply do not have the resources to do that.  The 1.x code (which is
>> still the guts of what is now in trunk) is complex and fragile.  I
>> am -1 for trying to support two versions of that code concurrently
>> and I do not think it would be a responsible decision for this PMC
>> to go down that path.
>>
>> Phil
>>
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Fri, May 6, 2011 at 5:54 PM, Paul Benedict <pbenedict@apache.org> wrote:
>>>> Is it too radical to suggest POOL 2 be 1.5 and POOL 3 be 1.6? Just
>>>> bump up major version every time you target a new major JDK.
>>>>
>>>> On Fri, May 6, 2011 at 10:35 AM, Mark Thomas <markt@apache.org> wrote:
>>>>> On 06/05/2011 16:24, Phil Steitz wrote:
>>>>>> 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?
>>>>> Yes I agree. To address 0), we need to remove most/all of the
>>>>> synchronisation around object allocation. That means a re-write, almost
>>>>> certainly with java.u.c. I still have concerns around 1) & 2). The more
>>>>> I think about this problem, the more I realise I need to spend more time
>>>>> thinking about the problem. At the moment, I would rather take the time
>>>>> and get this right.
>>>>>
>>>>>>> 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?
>>>>> Sure. In pool1 we have the ability (via CursorableLinkedList) to remove
>>>>> and insert idle objects at any point in the queue. We use this for the
>>>>> evictor and idle validation. It we switch to java.u.c (and I think it is
>>>>> almost certain we will have to to get the performance we want) there are
>>>>> far fewer options over object insertion/creation.
>>>>>
>>>>> In Java 1.5, LinkedBlockingQueue only supports FIFO. It is not possible
>>>>> to remove from the tail of the queue or insert at the head. That makes
>>>>> LIFO pretty much impossible to implement.
>>>>>
>>>>> In Java 1.6, LinkedBlockingDeque allows inserts and removals at either
>>>>> end of the queue. That solves the LIFO/FIFO issue but not the eviction /
>>>>> idle validation questions. I have some ideas about this but I am trying
>>>>> to avoid creating lots of complexity. I am also mulling over how to
>>>>> ensure that maxActive and friends are adhered to.
>>>>>
>>>>> 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
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
> ---------------------------------------------------------------------
> 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