Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-63047

Upgrade Groovy to 2.5.6+ to address OOM / Memory leak

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: core, job-dsl-plugin
    • Labels:
      None
    • Environment:
      Jenkins v2.190.2
      Job DSL v1.77
    • Similar Issues:

      Description

      TL;DR
      We would like to know if it is possible (or already on your roadmap) to upgrade the version of Groovy in jobdsl-plugin/jenkins-core as we believe it will help with a memory leak we've been seeing.

      Background
      We have a use case in our jenkins deployment where we build pipelines via the jobdsl plugin. We have noticed that when we execute this process multiple times we eventually run out of memory.

      After lots of investigation and heap dump analysis we believe the issue is related to https://issues.jenkins-ci.org/browse/JENKINS-46687 and that the constant use of the GroovyShell.parse / parseClass eventually exhausts the memory. Part of the analysis that leads us to believe this is the attached heap analysis showing that there are instances of the MetaMethodIndex class that are never garbage collected. 

      We did try and set -Dgroovy.use.classvalue=true as per https://issues.jenkins-ci.org/browse/JENKINS-33358 , but that doesnt seem to work for us.

      Looking at this comment in the groovy issues it suggests that upgrading to 2.5.6+ will help improve the evaluation of scripts in Groovy.

      So we are wondering if it is possible to schedule (if not already scheduled) the upgrade of Groovy version? Or maybe even if you could suggest some other potential causes of the problem / solutions to try out?

      Please let us know if you need more detail around this.

       

        Attachments

          Issue Links

            Activity

            Hide
            daspilker Daniel Spilker added a comment -

            Speaking for Job DSL, I would support updating to 2.5.x and I am willing to make the necessary changes in Job DSL.

            There has been a PR for Jenkins core, but it has been closed. See
            https://github.com/jenkinsci/jenkins/pull/3605. As mentioned in the closing comment by Daniel Beck this needs to be a joint effort as not only core and job-dsl are affected. There needs to be someone driving the process, e.g. starting a discussion on the mailing list. Chris Berry can you do that?

            Show
            daspilker Daniel Spilker added a comment - Speaking for Job DSL, I would support updating to 2.5.x and I am willing to make the necessary changes in Job DSL. There has been a PR for Jenkins core, but it has been closed. See https://github.com/jenkinsci/jenkins/pull/3605 . As mentioned in the closing comment by Daniel Beck this needs to be a joint effort as not only core and job-dsl are affected. There needs to be someone driving the process, e.g. starting a discussion on the mailing list. Chris Berry can you do that?
            Hide
            danielbeck Daniel Beck added a comment -

            Unless one of (Devin, Andrew, Jesse) is willing to do the work in Pipeline, this is DOA.

            Show
            danielbeck Daniel Beck added a comment - Unless one of (Devin, Andrew, Jesse) is willing to do the work in Pipeline, this is DOA.
            Hide
            bez625 Chris Berry added a comment -

            Daniel Beck Daniel Spilker - thank you both very much for your responses and linking to the github PR - I hadnt thought to check there! I discussed this with my colleagues and we will close the issue for the following reasons:

            1. We do not know for certain this will improve/ease the issue we are facing and it sounds like it could actually raise more issues based on how previous updates to Groovy have gone.
            2. Even if we proved out the first point I do not think we are willing to invest the time and effort it will take to develop and test that the upgrade is safe. Especially when there may be little or no feature benefit to anyone but us.
            Show
            bez625 Chris Berry added a comment - Daniel Beck Daniel Spilker - thank you both very much for your responses and linking to the github PR - I hadnt thought to check there! I discussed this with my colleagues and we will close the issue for the following reasons: We do not know for certain this will improve/ease the issue we are facing and it sounds like it could actually raise more issues based on how previous updates to Groovy have gone. Even if we proved out the first point I do not think we are willing to invest the time and effort it will take to develop and test that the upgrade is safe. Especially when there may be little or no feature benefit to anyone but us.

              People

              • Assignee:
                bez625 Chris Berry
                Reporter:
                bez625 Chris Berry
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated: