You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Antoine Brochard (JIRA)" <ji...@apache.org> on 2011/07/06 22:59:16 UTC
[jira] [Updated] (JCR-3008) Memory leak due to TransactionContext
and java.util.Timer
[ https://issues.apache.org/jira/browse/JCR-3008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antoine Brochard updated JCR-3008:
----------------------------------
Description:
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?
was:
I observed that sometimes when working on large write operations, instances of TransactionContext stay referenced by an instance of java.util.TaskQueue
I may be wrong but
In TransactionContext.prepare() the rollback task is scheduled :
timer.schedule(this, timeout * 1000, Integer.MAX_VALUE);
Then in java.util.Timer:
- if the rollback task has not been cancelled yet ( for example if a large commit is in progress ) when the TimerThread get to work on it
- and the timeout expired ( executionTime<currentTime)
then since the period is set to Integer.MaxValue, and other tasks are in the same queue, the next time the task is examined and removed from the queue may be in several days !!
If my analysis is correct I have several proposals
- the period parameter could be omitted when calling the schedule method
- a call to Timer.purge() could be made after cancelling the task
hope this helps
Environment: jdk 1.6 (was: jdk 1.6.0_24)
Summary: Memory leak due to TransactionContext and java.util.Timer (was: Possible Memory leak due to TransactionContext and java.util.Timer)
> 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