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:46:50 GMT
On 5/11/11 5:42 AM, Mark Thomas wrote:
> On 11/05/2011 11:31, Mark Thomas wrote:
>> On 11/05/2011 04:34, Phil Steitz wrote:
>>> On 5/10/11 7:26 PM, 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?  ArrayBlockingQueue is an alternative
>>>> that does support fairness; but then I guess we lose LIFO/FIFO
>>>> control and probably performance.  Any ideas how we could get
>>>> fairness, or at least some control over fairness to work?  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 :)
>>> After looking quickly at the Harmony code for LinkedBlockingDeque,
>>> we may be able to solve both the 1.6 problem and fairness by
>>> bringing that source in and just making the ReentrantLock that it
>>> uses configurable to be either fair or not (as ArrayBlockingQueue
>>> does).  Might be naive, but might work.
>> I like it. A lot. Great idea.
> Better still, it is faster than whatever Oracle wrote for Java 6 :)
> With this in place, DBCP is slightly faster than jdbc-pool for
> jdbc-pools checkout thread tests. This is only two microbenchmarks
> (there are lots of other tests where jdbc-pool is faster but I haven't
> optimized DBCP for those yet) but it is a promising sign.
>
> I just need to tidy up the code before I check it in.

Great!  I also now have [performance] set up to run pool2 tests
directly.  I have just started testing.  I will post results as I
get them and also for [dbcp] with the new pool.  Don't forget to
re-enable the fairness unit test once that is working.

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