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

Numerous uncached calls to ParserRegistry.getAllParsers

    Details

    • Similar Issues:

      Description

      Analysis of thread dumps from a user complaining of long page load times turned up the following alarming stack trace from the HTTP handler thread for a job index page:

      	at java.lang.ClassLoader.findLoadedClass0(Native Method)
      	at java.lang.ClassLoader.findLoadedClass(ClassLoader.java:1084)
      	at java.lang.ClassLoader.loadClass(ClassLoader.java:405)
      	-  locked hudson.ClassicPluginStrategy$DependencyClassLoader@6afbff2a
      	at java.lang.ClassLoader.loadClass(ClassLoader.java:410)
      	-  locked java.lang.Object@7c1b6747
      	at java.lang.ClassLoader.loadClass(ClassLoader.java:410)
      	-  locked groovy.lang.GroovyClassLoader@4cbc11ae
      	at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:696)
      	at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:564)
      	at org.codehaus.groovy.control.ResolveVisitor.resolveToClass(ResolveVisitor.java:709)
      	at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:275)
      	at org.codehaus.groovy.control.ResolveVisitor.resolveFromStaticInnerClasses(ResolveVisitor.java:441)
      	at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:275)
      	at org.codehaus.groovy.control.ResolveVisitor.resolveFromStaticInnerClasses(ResolveVisitor.java:441)
      	at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:275)
      	at org.codehaus.groovy.control.ResolveVisitor.resolveFromStaticInnerClasses(ResolveVisitor.java:441)
      	at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:275)
      	at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1241)
      	at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:148)
      	at org.codehaus.groovy.control.CompilationUnit$9.call(CompilationUnit.java:605)
      	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:843)
      	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:548)
      	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:497)
      	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:306)
      	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:287)
      	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731)
      	at groovy.lang.GroovyShell.parse(GroovyShell.java:743)
      	at groovy.lang.GroovyShell.parse(GroovyShell.java:770)
      	at groovy.lang.GroovyShell.parse(GroovyShell.java:761)
      	at hudson.plugins.warnings.GroovyParser$DescriptorImpl.doCheckScript(GroovyParser.java:265)
      	at hudson.plugins.warnings.GroovyParser.isValid(GroovyParser.java:106)
      	at hudson.plugins.warnings.parser.ParserRegistry.getDynamicParsers(ParserRegistry.java:227)
      	at hudson.plugins.warnings.parser.ParserRegistry.getAllParsers(ParserRegistry.java:207)
      	at hudson.plugins.warnings.parser.ParserRegistry.getUrl(ParserRegistry.java:151)
      	at hudson.plugins.warnings.WarningsDescriptor.getProjectUrl(WarningsDescriptor.java:74)
      	at hudson.plugins.warnings.WarningsProjectAction.createUserConfiguration(WarningsProjectAction.java:60)
      	at hudson.plugins.analysis.core.AbstractProjectAction.isTrendVisible(AbstractProjectAction.java:219)
      	...JEXL...
      

      Here ParserRegistry.getUrl is doing a linear search against the result of getAllParsers, which is in turn not only uncached, but forces expensive Groovy compilation. In fact if I set a breakpoint in GroovyParser just prior to the call to GroovyShell.parse, create a single custom warning (using the simple format in the plugin's inline help), create a job which just echoes

      some/file:33:deprecation: you did not want to do this!
      

      to console, run it, and load the #1 build index page, I guess nine calls (attached), arising from various bits of Jelly rendering. (The stack trace above is distinct so apparently a tenth instance, though I did not manage to reproduce it.)

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                drulli Ulli Hafner
                Reporter:
                jglick Jesse Glick
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: