commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r1101516 - in /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl:
Date Wed, 11 May 2011 10:30:51 GMT
On 11/05/2011 03:26, Phil Steitz wrote:
> On 5/10/11 8:48 AM, wrote:
>> Author: markt
>> Date: Tue May 10 15:48:22 2011
>> New Revision: 1101516
>> URL:
>> Log:
>> Move to using LinkedBlockingDeque for the queue of idle objects.
> Definitely simpler, cleaner code, but seems there will be no easy
> way to enable fairness and some badly "unfair" stuff can happen when
> clients get instances under maintenance.  In theory, an unlucky
> client could wait forever.  Do we have any data on how "unfair"
> LinkedBlockingDeque can be?

No. I suspect it will be as bad as the old non-fair DBCP implementation.

> ArrayBlockingQueue is an alternative
> that does support fairness; but then I guess we lose LIFO/FIFO
> control and probably performance.

Losing LIFO/FIFO is a non-starter in my view.

> Any ideas how we could get fairness, or at least some control over fairness to work?

My best ideas so far was to copy jdbc-pool's approach and wrap the Deque
and provide fair locking in the wrapper.

> Another
> thing to think about is whether clients are better off waiting for
> the state change on instances under maintenance than getting back in
> line for the next available instance. (I now see the fairness TODO
> in TestGOP :)

It depends how busy the pool is. If there are other idle instances,
getting back in line will be fine. If the pool is exhausted, better to
wait for the instance currently being tested.

On reflection, it should be possible to allow borrowing to over-ride an
in-progress eviction test. That should always be the fastest solution.


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

View raw message