On 23/03/2011 22:13, Phil Steitz wrote: > On 3/23/11 2:01 PM, Mark Thomas wrote: >> On 23/03/2011 17:46, Phil Steitz wrote: >>> Do we need to worry about leaking memory here due to things never >>> getting removed from _poolMap, _poolList? >> I don't think so. The entries should only exit in _poolMap and _poolList >> while associated objects exist. >> > Looking carefully at both 1.5.5 and 1.5.x current code, I can see > the situation is better now; but I still can't see _poolMap reliably > cleaned up if clear is invoked when an instance failing validation > is in process of being destroyed. I am not sure there is an easy > way to fix this, since we need to keep the _poolMap entry around to > keep accounting correct.
Thanks for the analysis. In that scenario, allowing for the synchronisation, there are four different code blocks that could end being the lest to execute: - clear() -> destroy(Map, KeyedPoolableObjectFactory) -> clean up - evict() -> clean up needs to move to end of method - borrowObject() -> no clean up (doesn't matter since we need to create) - return() -> no clean up (can be added) I have a patch that makes the necessary changes (and fixes a unit test that fails now the keys are retained to track active count). I just need to run the unit tests and port the changes to trunk. Mark > > Phil > >>> Also, IIUC what is going on here, we need to make a similar change >>> the evict() where the last instance in a keyed pool is evicted. >> It certainly looks like it. However, this is highlighting some issues (I >> think in the tests). I'll try and look at this tomorrow. >> >> Mark >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
