• Icon: Patch Patch
    • Resolution: Fixed
    • Icon: Major Major
    • subversion-plugin
    • None
    • Platform: All, OS: All

      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.

          [JENKINS-886] Memoryleak in subversion SCM for Hudson

          lothor added a 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

          lothor added a 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

          jbq added a comment -

          Have you tested this patch successfully in the long run? Do you still
          experience memory leaks?

          jbq added a comment - Have you tested this patch successfully in the long run? Do you still experience memory leaks?

          lothor added a 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.

          lothor added a 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.

          lothor added a 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)

          lothor added a 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)

          recht added a 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.

          recht added a 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.

          recht added a comment -

          Created an attachment (id=110)
          Testcase for memory leak

          recht added a comment - Created an attachment (id=110) Testcase for memory leak

          recht added a comment -
              • Issue 870 has been marked as a duplicate of this issue. ***

          recht added a comment - Issue 870 has been marked as a duplicate of this issue. ***

          jbq added a 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.

          jbq added a 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.

            Unassigned Unassigned
            lothor lothor
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: