[
https://issues.apache.org/jira/browse/POOL-386?focusedWorklogId=461806&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-461806
]
ASF GitHub Bot logged work on POOL-386:
---------------------------------------
Author: ASF GitHub Bot
Created on: 22/Jul/20 00:37
Start Date: 22/Jul/20 00:37
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_r458466835
##########
File path:
src/main/java/org/apache/commons/pool2/impl/BaseGenericObjectPool.java
##########
@@ -783,12 +783,21 @@ final void assertOpen() throws IllegalStateException {
*/
final void startEvictor(final long delay) {
synchronized (evictionLock) {
- EvictionTimer.cancel(evictor, evictorShutdownTimeoutMillis,
TimeUnit.MILLISECONDS);
- evictor = null;
- evictionIterator = null;
- if (delay > 0) {
- evictor = new Evictor();
- EvictionTimer.schedule(evictor, delay, delay);
+ if (evictor == null) { // Starting evictor for the first time or
after a cancel
+ if (delay > 0) { // Starting new evictor
+ evictor = new Evictor();
+ EvictionTimer.schedule(evictor, delay, delay);
+ }
+ } else { // Stop or restart of existing evictor
+ if (delay > 0) { // Restart
+ EvictionTimer.cancel(evictor,
evictorShutdownTimeoutMillis, TimeUnit.MILLISECONDS, true);
+ evictor = null;
+ evictionIterator = null;
+ evictor = new Evictor();
+ EvictionTimer.schedule(evictor, delay, delay);
+ } else { // Stopping evictor
Review comment:
Good catch. I got confused about lock scope (evictionlock is not quite
enough to protect here :). I guess syncing the whole block on EvictionTimer
class lock would prevent that, but only for low probability efficiency gain.
Not sure how to fix this other than that. Did not change this.
Thanks for review!
----------------------------------------------------------------
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: 461806)
Time Spent: 1h 50m (was: 1h 40m)
> 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: 1h 50m
> 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)
