[
https://issues.apache.org/jira/browse/JCR-3008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061044#comment-13061044
]
Peter Dettman commented on JCR-3008:
------------------------------------
A small change that would improve things greatly would be to set the delay for
the rollback task to (say) 1000 (the rollback itself is idempotent, so this
should be safe). java.util.TimerThread unfortunately requires the task to "come
around" again before it will notice it's been cancelled and remove it from the
queue.
> Memory leak due to TransactionContext and java.util.Timer
> ---------------------------------------------------------
>
> Key: JCR-3008
> URL: https://issues.apache.org/jira/browse/JCR-3008
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 2.2.1, 2.2.4, 2.2.5, 2.2.7
> Environment: jdk 1.6
> Reporter: Antoine Brochard
> Labels: memory, memory_leak, perfomance
>
> When working on large write operations, instances of TransactionContext may
> stay referenced by an instance of java.util.TaskQueue long after the task
> has been cancelled
> In TransactionContext.prepare() the rollback task is scheduled :
> timer.schedule(this, timeout * 1000, Integer.MAX_VALUE);
> In java.util.Timer looking at TimerThread.mainLoop() since the period is set
> to Integer.MaxValue and recurrent tasks are in the queue, the task may stay
> in the queue a lot longer than expected. This can lead to OutOfMemory errors.
>
> The org.apache.jackrabbit.util.Timer could be modified to add a method to
> schedule tasks without period.
> Or a call to Timer.purge() could be made in
> org.apache.jackrabbit.util.Task.cancel()
> What do you think?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
