I have some code that seemed to work against SVNKit 1.36.1 but causes a
memory leak against 1.7.10.
A custom Jenkins SCM plugin that runs with the subversion plugin
under multi-scm needs to do an export using credentials managed by the
subversion plugin. I constuct an SVNUpdateClient object, call doExport, and
then everything goes out of scope:
private void foo(AbstractProject context,
File config_dir,
String manifest_url,
File manifest_file)
{
DefaultSVNOptions svn_options =
SVNWCUtil.createDefaultOptions(true);
svn_options.setAuthStorageEnabled(true);
// Call into jenkins subversion plugin code
ISVNAuthenticationProvider auth_provider =
Hudson.getInstance().getDescriptorByType(
SubversionSCM.DescriptorImpl.class).
createAuthenticationProvider(context);
ISVNAuthenticationManager auth_manager =
SVNWCUtil.createDefaultAuthenticationManager(
config_dir, null, null);
auth_manager.setAuthenticationProvider(auth_provider);
SVNUpdateClient svn_client =
new SVNUpdateClient(auth_manager, svn_options);
svn_client.doExport(SVNURL.parseURIEncoded(manifest_url),
manifest_file,
SVNRevision.HEAD,
SVNRevision.HEAD,
null,
true,
SVNDepth.FILES);
}
Without the above code things are fine. With it executing repeatedly over
time the memory footprint grows continuously. Heap dump analysis shows:
One instance of
"java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue" loaded
by "<system class loader>" occupies 154,233,944 (48.93%) bytes. The
instance is referenced by
org.tmatesoft.svn.core.wc.DefaultSVNRepositoryPool @ 0x207aee88 , loaded by
"hudson.ClassicPluginStrategy$AntClassLoader2 @ 0x1d2f53e8". The memory is
accumulated in one instance of
"java.util.concurrent.RunnableScheduledFuture[]" loaded by "<system class
loader>".
Can anyone suggest what I might be doing wrong? Thanks!
--
View this message in context:
http://subversion.1072662.n5.nabble.com/Memory-leak-moving-from-1-36-1-to-1-7-10-tp187537.html
Sent from the SVNKit - Users mailing list archive at Nabble.com.
