commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin (JIRA)" <j...@apache.org>
Subject [jira] Commented: (POOL-97) EVICTION_TIMER is never cancelled.
Date Sun, 22 Jul 2007 18:40:06 GMT

    [ https://issues.apache.org/jira/browse/POOL-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514495
] 

Robert Burrell Donkin commented on POOL-97:
-------------------------------------------

This fix breaks binary compatibility but only at package private level. 

One question which may need to investigated is whether any subtle concurrency issues are prevent
by using a static instance. I've taken a look at the code and i can only see it being used
to set up eviction timings. Not sure whether these are ever cleared out. So, the instance
will ensure the pool remains in memory until the server is restarted. More eyes would be good
since it's very easy to miss subtle concurrency issues.

I suppose that some benchmarks would be the right way to assess the performance impact of
this patch. 

A more complex solution would be to create a private subclass of timer that does knows when
to unschedule eviction tasks. The evictor would need to implement a package interface (unschedulable?)
and then test for the pool being closed (or something like that). This would be quite a bit
more effort with more to go wrong. 

> EVICTION_TIMER is never cancelled.
> ----------------------------------
>
>                 Key: POOL-97
>                 URL: https://issues.apache.org/jira/browse/POOL-97
>             Project: Commons Pool
>          Issue Type: Bug
>    Affects Versions: 1.3
>            Reporter: Devendra Patil
>             Fix For: 2.0
>
>         Attachments: timer.patch
>
>
> The static EVICTION_TIMER (java.util.Timer) used in GenericObjectPool is never cancelled
(even after closing the pool). The GenericObjectPool.close() method just cancels the _evictor
(TimerTask). I agree this behaviour is ideal if EVICTION_TIMER is to be used across multiple
pools.
> But, In my case, the resources (i.e. jars) are dynamically deployed and undeployed on
remote grid-servers. If EVICTION_TIMER thread doesn't stop, the grid-servers fails to undeploy
(i.e. delete) the jars. The grid-server doesn't restart during resource deployment/undeployment,
so, setting EVICTION_TIMER to daemon doesn't help me.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message