[
https://issues.apache.org/jira/browse/JCR-3008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine Brochard updated JCR-3008:
----------------------------------
Affects Version/s: 2.2.4
2.2.5
2.2.7
Looking at the code this should also apply at least to 2.2.4, 2.2.5 , 2.2.7
> Possible 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.0_24
> Reporter: Antoine Brochard
> Labels: memory, memory_leak, perfomance
>
> 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
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
