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
