Repository navigation
[JENKINS-886] Memoryleak in subversion SCM for Hudson #412
Description
When running Hudson for extended periods of time with the SCM polling interval
set to 1-5 minutes depending on the project being built I've been having some
problems with OutOfMemoryErrors after running Hudson for about a week or two.
After looking into the problem using the YourKit Java profiler I've I've noticed
a fairly consistent leak with regards to the static Timer instance created by
SVNKit in org.tmatesoft.svn.core.wc.DefaultRepositoryPool. Whenever an instance
of DefaultRepositoryPool is registered it schedules an instance of the inner
class TimeoutTask to be run in 10 seconds. This task runs every 10 seconds,
closing and removing inactive repositories from the pools inactive repositories
collection.
Due to the timer thread being a GC root which holds a reference to the pool via
the TimeoutTasks synthetic reference to the pool instance the tasklist keeps on
growing forever due to dispose() never being called. After looking at the method
createSvnClientManager in hudson.scm.SubversionSCM and it seems that dispose()
is never called on the new instance of SVNClientManager by any of its callers.
Originally reported by lothor, imported from: Memoryleak in subversion SCM for Hudson
- status: Closed
- priority: Major
- component(s): subversion-plugin
- resolution: Fixed
- resolved: 2007-10-19T04:30:14+00:00
- votes: 0
- watchers: 0
- imported: 20251212-090250
Raw content of original issue
When running Hudson for extended periods of time with the SCM polling interval set to 1-5 minutes depending on the project being built I've been having some problems with OutOfMemoryErrors after running Hudson for about a week or two. After looking into the problem using the YourKit Java profiler I've I've noticed a fairly consistent leak with regards to the static Timer instance created by SVNKit in org.tmatesoft.svn.core.wc.DefaultRepositoryPool. Whenever an instance of DefaultRepositoryPool is registered it schedules an instance of the inner class TimeoutTask to be run in 10 seconds. This task runs every 10 seconds, closing and removing inactive repositories from the pools inactive repositories collection.
Due to the timer thread being a GC root which holds a reference to the pool via the TimeoutTasks synthetic reference to the pool instance the tasklist keeps on growing forever due to dispose() never being called. After looking at the method createSvnClientManager in hudson.scm.SubversionSCM and it seems that dispose() is never called on the new instance of SVNClientManager by any of its callers.
- environment:
Platform: All, OS: All
Activity
jenkins-infra-bot commentedon Oct 3, 2007
lothor:
Raw content of original comment:
Created an attachment (id=98)
My first attempt at a fix for the memoryleak, adds explicit call to dispose on SvnClientManager for all callers of createSvnClientManager
jenkins-infra-bot commentedon Oct 10, 2007
Raw content of original comment:
Have you tested this patch successfully in the long run? Do you still
experience memory leaks?
jenkins-infra-bot commentedon Oct 10, 2007
lothor:
Raw content of original comment:
My testing has limited itself to running a patched and unpatched version of
Hudson 1.144 over a period of 24 hours. Both versions were set up to use
identical, simulated copies of my production environment.
I'm was able to reproduce the leak in the unpatched version of Hudson by doing
the following:
1. Start Hudson (for my testing I've been running the warfile directly via java
-jar hudson.war, using java version 1.6.0-b105).
2. Create 30 free-style projects with the following configuration:
Source Code Management: Subversion
Repository URL: (http url to an empty subversion repository)
Build Triggers: Poll SCM
Schedule: * * * * * (poll subversion once every minute)
3. Connect to the java process running Hudson using JConsole
4. Run for 24 hours
After running the unpatched version for 24 hours the memory utilization in the
tenured generation was more or less constantly growing. The memory utilization
for the patched version on the other hand stayed fairly constant throughout the
same period.
jenkins-infra-bot commentedon Oct 11, 2007
lothor:
Raw content of original comment:
The description of the build configuration in step 2 of my previous comment was
incorrect, the correct description is as follows:
2. Create 30 free-style projects with the following configuration:
Source Code Management: Subversion
Repository URL: (http url to an empty subversion repository)
Build Triggers: Build periodically
Schedule: * * * * * (execute a build once every minute)
jenkins-infra-bot commentedon Oct 17, 2007
recht:
Raw content of original comment:
I can confirm that the patch actually fixes the leak. I've created an attachment
with a simple testcase, which displays the behavior pretty clearly. Without the
patch, memory usage just goes up, with the patch applied, memory usage remains
constant.
jenkins-infra-bot commentedon Oct 17, 2007
recht:
Raw content of original comment:
Created an attachment (id=110)
Testcase for memory leak
jenkins-infra-bot commentedon Oct 17, 2007
recht:
Raw content of original comment:
jenkins-infra-bot commentedon Oct 19, 2007
Raw content of original comment:
Thanks all for your contributions. Both the patch and the test case were
valuable. Applied the patch, and added the testcase in Hudson tester's
Issue886Test.
jenkins-infra-bot commentedon Dec 12, 2025
[Original
is_duplicated_byfrom Jira: JENKINS-870]