commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <>
Subject [jira] [Commented] (POOL-287) GKOP can lose objects over time due to swallowed NPE in the evictor
Date Sat, 21 Feb 2015 16:36:11 GMT


Phil Steitz commented on POOL-287:

I am inclined to fix this by turning the evictionIterator into a class that holds a reference
to its underlying collection.  Otherwise, we need to always set idleObjects which is a little
tricky and may have slight performance impact.  It also seems a little brittle to me to have
to recover the pool reference across evictor runs.   Any objections or better ideas?  I suppose
another logical alternative would be to have DefaultPooleObject itself hold a reference to
its owning pool.

> GKOP can lose objects over time due to swallowed NPE in the evictor
> -------------------------------------------------------------------
>                 Key: POOL-287
>                 URL:
>             Project: Commons Pool
>          Issue Type: Bug
>    Affects Versions: 2.2, 2.3
>            Reporter: Caleb Spare
>         Attachments: POOL-287-test.patch
> We ran into this bug via a Redis library that uses a GenericKeyedObjectPool for connection
pooling. We found that over the course of several days, the connections available to our application
were dwindling.
> Some relevant configuration:
> testWhileIdle: false
> numTestsPerEvictionRun: -1
> minEvictableIdleTimeMillis: 60000
> timeBetweenEvictionRunsMillis: 30000
> maxTotalPerKey 400
> maxIdlePerKey 400
> (In a more minimal repro case I developed later, the problem happens much faster if minEvictableIdleTimeMillis
and timeBetweenEvictionRunsMillis are reduced greatly, even down to 1.)
> We discovered that this is what happens (looking at 2.3 code, but the problem occurred
with 2.2 and 2.3):
> * In evict(), there is a variable idleObjects which starts as null
> * The branch where idleObjects is set is not necessarily taken
> * The null idleObjects is passed to underTest.endEvictionTest(idleObjects)
> * If the object underTest had previously been borrowed and was thus set to the  EVICTION_RETURN_TO_HEAD
state, then endEvictionTest throws a NPE
> * By default this is silently swallowed and the evictor continues on
> * Now the object that had been underTest is set to state IDLE, but is not in the pool's
idleObjects list, so it is lost
> If it would help, I can clean up my repro program and attach that, but it is written
in Clojure, not Java. I can also try to write a Java repro but I might not have time to do
that for a little while.
> This bug can be avoided by disabling the evictor. That doesn't help us, though, because
we rely on background eviction to avoid running into server-side connection timeouts.

This message was sent by Atlassian JIRA

View raw message