-
Bug
-
Resolution: Fixed
-
Major
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.)
- is duplicated by
-
-
- Resolved
-