Phil Steitz wrote: > I just saw this in one of my load tests > > [java] java.util.NoSuchElementException > [java] at java.util.LinkedList.remove(LinkedList.java:644) > [java] at java.util.LinkedList.removeFirst(LinkedList.java:134) > [java] at > org.apache.commons.pool.impl.GenericKeyedObjectPool.allocate(GenericKeyedObjectPool.java:1248) > > [java] at > org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1091) > > > Looks to me like before entering the permit-dispensing block, we need to > make sure there are latches left to be served in the allocation queue.
Having looked at the code I don't see what you mean. Pretty much all of allocate() is inside a if (!_allocationQueue.isEmpty()) block. I'm having trouble seeing how you managed to hit this bug. > IIRC what is going on, this should happen (so could be unit-tested) > when there are n threads waiting and m instances in one of the pools, > with n < = m < maxActive, so they all get served from the idle pool, but > there is still capacity to create. Could you elaborate on how you think this occurred? As an aside, did your test environment include the change in r778357? Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
