commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [pool] Liveness issue in GKOP
Date Sun, 18 Sep 2011 17:17:08 GMT
I am pretty sure that the analysis above is correct.  We need a way
to either wake up the waiting threads and allow them to create when
there is total capacity or push instances to the queues they are
waiting on.  This is less of a problem for GOP, because invalidate
is the only way it can happen; but it is real problem for GKOP -
basically the same problem that led to clearOldest, but
re-introduced now because we don't wait-notify any more.  My first
thought for a fix was

0) modify our LinkedBlockingQueue to expose a hasTakeWaiters or
numTakeWaiters method based on its ReentrantLock (probably useful in
any case for monitoring) and modify clearOldest to walk the key list
and add to queues with (the most) waiters, doling out the capacity
it just created "fairly."

This would work, but its not really fair to the client that gets
stuck waiting for the now even more boggy clearOldest to complete. 
That led me to

1) change the contract so that if you want clearOldest and
feed-the-hungry functionality, you need to enable the maintenance
thread.  Then move clearOldest, augmented to also serve some
waiters, to the maintenance task. 

Another possibility is

2) introduce a FutureTask to do try to do creates after clearOldest
or combine this with clearOldest in a FutureTask, kicked off as
clearOldest is now by a client borrow request.


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

View raw message