commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Honton, Charles" <Charles_Hon...@intuit.com>
Subject Re: [POOL2] Java 1.5 or 1.6?
Date Fri, 06 May 2011 16:00:30 GMT
Consider ArrayBlockingQueue.  It has ability to remove a specified element
from queue.  Also, it is bounded, which is probably desirable.

Chas


On 5/6/11 11: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


Mime
View raw message