Description of problem:

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.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. configure long ejb timeout with the Nonpassivating or PassivatingBackingCache
2. put load on the ejb

Actual results:

Cancelled tasks can pile in the executor's DelayedWorkQueue.


Expected results:

Cancelled tasks are flushed out of the executor's DelayedWorkQueue more eagerly.


Additional info:

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