The change in r1174432 stopped tests from hanging, but the fix there was for a different liveness problem. I just committed a test, testLivenessPerKey that provides a simple example of what can go wrong. It also shows that approach 0) below will not work (because clearOldest is called on borrow/create and that may be too early). I have coded a fix that kicks off capacity reuse (creates pushed to queues) at the end of returnObject, using waiter counts to decide what queue to serve. That works, but, like clearOldest, it carries a cost. Unless I hear objections, I will go ahead and commit the fix. We can move the reuseCapacity method that does the creates into the evictor if the performance hit is too bad on returnObect or do something better if someone has a better idea.
Phil On 9/18/11 10:17 AM, Phil Steitz wrote: > 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. > > > Phil > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
