commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: svn commit: r1101516 - in /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl: GenericObjectPool.java PooledObject.java PooledObjectState.java
Date Wed, 11 May 2011 14:35:37 GMT
On 5/11/11 3:30 AM, Mark Thomas wrote:
> On 11/05/2011 03:26, Phil Steitz wrote:
>> On 5/10/11 8:48 AM, markt@apache.org wrote:
>>> Author: markt
>>> Date: Tue May 10 15:48:22 2011
>>> New Revision: 1101516
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1101516&view=rev
>>> 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.

Also depends on which kind of maintenance is happening when the
client arrives (validation or expiry testing) and how fast
validation is.
> On reflection, it should be possible to allow borrowing to over-ride an
> in-progress eviction test. That should always be the fastest solution.

I thought about that too; but it would be tricky to do.  Depends on
at what point the borrower arrives during the maintenance visit.  If
the instance is actually in process of being destroyed or tested,
would be dicey to try to break in.  Have to be very careful with the
locks if we implement this.

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


Mime
View raw message