[jboss-jira] [JBoss JIRA] (WFLY-2521) EJB backing cache's can generate large retention from cancelled tasks in its scheduled executor's DelayedWorkQueue

[RH Bugzilla Integration (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925372#comment-12925372 ] 

RH Bugzilla Integration commented on WFLY-2521:
-----------------------------------------------

Paul Ferraro <paul.ferraro at redhat.com> made a comment on [bug 1031199|https://bugzilla.redhat.com/show_bug.cgi?id=1031199]

Good catch.  I've updated the PR.
                
> EJB backing cache's can generate large retention from cancelled tasks in its scheduled executor's DelayedWorkQueue
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2521
>                 URL: https://issues.jboss.org/browse/WFLY-2521
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Assignee: Paul Ferraro
>
> EJB backing cache's frequently cancel remove and passivation tasks with each access and replace them with new ones.  Per http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html cancelled tasks are not removed from queue until their scheduled delay passes.
> So due to the java ScheduledThreadPoolExecutor's lazy cancelled task removal, this scheduled task cancellation and recreation model can potentially churn up quite a number of queued cancelled tasks sitting in the executor's DelayedWorkQueue.  With longer timeouts and frequent ejb access, this can generate substantial heap overhead.
> It should be pretty easy to help limit any such build up by calling purge() [1] on the scheduled executor.  Likely don't want to purge with each cancel, so perhaps a purge() could be called on a configurable time delay or after a configurable amount of cancels?
> [1] http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html#purge%28%29

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira