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

Paul Ferraro (JIRA) jira-events at lists.jboss.org
Mon Nov 18 18:11:07 EST 2013


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

Paul Ferraro commented on WFLY-2521:
------------------------------------

[~dmlloyd] That's a good point.  It looks like queue removal is an O(N) operation - so even setRemoveOnCancelPolicy(true) is not ideal.  I'll open a separate jira to address this.
                
> 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


More information about the jboss-jira mailing list