[
https://issues.apache.org/jira/browse/POOL-386?focusedWorklogId=462777&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-462777
]
ASF GitHub Bot logged work on POOL-386:
---------------------------------------
Author: ASF GitHub Bot
Created on: 24/Jul/20 01:17
Start Date: 24/Jul/20 01:17
Worklog Time Spent: 10m
Work Description: psteitz commented on a change in pull request #32:
URL: https://github.com/apache/commons-pool/pull/32#discussion_r459810041
##########
File path:
src/test/java/org/apache/commons/pool2/impl/TestGenericObjectPool.java
##########
@@ -2996,4 +2909,24 @@ public void testWhenExhaustedFail() throws Exception {
genericObjectPool.close();
}
+ /**
+ * Check that a pool that starts an evictor, but is never closed does not
+ * leave EvictionTimer executor running. Confirmation check is in teardown.
+ */
+ @Test
+ public void testAbandonedPool() throws Exception {
+ GenericObjectPoolConfig config = new GenericObjectPoolConfig();
+ config.setJmxEnabled(false);
+ GenericObjectPool<String> abandoned = new
GenericObjectPool<>(simpleFactory, config);
+ abandoned.setTimeBetweenEvictionRunsMillis(100); // Starts evictor
+
+ // This is ugly, but forces gc to hit the pool
Review comment:
Yes, that is why it has to be done in a loop. Suggestions for a better
way to test this welcome. The teardown method verifies that there are no
abandoned evictor tasks. It will fail unless the weak reference held by the
EvictionTimer to this pool's evictor is cleared. All other pool tests
(correctly) close their pools.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 462777)
Time Spent: 2.5h (was: 2h 20m)
> Closing a pool can cause Evictor in another pool to be cancelled
> ----------------------------------------------------------------
>
> Key: POOL-386
> URL: https://issues.apache.org/jira/browse/POOL-386
> Project: Commons Pool
> Issue Type: Task
> Affects Versions: 2.6.1, 2.6.2, 2.7.0, 2.8.0
> Reporter: Phil Steitz
> Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The fix for POOL-337 introduced a race condition that can cause the shared
> EvictionTimer to be cancelled when a pool is closed but another pool still
> has an active Evictor. The EvictionTimer cancel method used to cancel an
> eviction task owned by a client pool uses this test to determine whether or
> not to shutdown its executor:
> {code:java}
> if (executor != null && executor.getQueue().isEmpty()){code}
> The executor may report an empty queue if it is executing a task. This will
> cause the executor to be shut down and scheduling of new tasks to stop.
> The unit test below illustrates the problem.
> {code:java}
>
> public void testEvictionTimerMultiplePools() throws InterruptedException {
> final AtomicIntegerFactory factory = new AtomicIntegerFactory();
> factory.setValidateLatency(50);
> final GenericObjectPool<AtomicInteger> evictingPool = new
> GenericObjectPool<>(factory);
> evictingPool.setTimeBetweenEvictionRunsMillis(100);
> evictingPool.setNumTestsPerEvictionRun(5);
> evictingPool.setTestWhileIdle(true);
> evictingPool.setMinEvictableIdleTimeMillis(50);
> for (int i = 0; i < 10; i++) {
> try {
> evictingPool.addObject();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> for (int i = 0; i < 1000; i++) {
> GenericObjectPool<AtomicInteger> nonEvictingPool = new
> GenericObjectPool<>(factory);
> nonEvictingPool.close();
> }
> Thread.sleep(1000);
> Assert.assertEquals(0, evictingPool.getNumIdle());
> evictingPool.close();
> }
> {code}
> Proposed fix:
> Change the test guarding executor shutdown to
> {code:java}
> executor.getQueue().isEmpty() && executor.getActiveCount() == 0
> {code}
> This still exposes a low-probability race - a task completes after the
> isEmpty test and is requeued before the activecount test - but this is very
> unlikely.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
