commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <>
Subject Re: [POOL2] Java 1.5 or 1.6?
Date Fri, 06 May 2011 16:29:08 GMT
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.
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.

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

Have a nice day, all the best,

On Fri, May 6, 2011 at 6:15 PM, Phil Steitz <> 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
>> On Fri, May 6, 2011 at 5:54 PM, Paul Benedict <> 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 <> 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:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message