-
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
-
[JENKINS-16526] Numerous uncached calls to ParserRegistry.getAllParsers
Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/hudson/plugins/warnings/GroovyParser.java
src/main/java/hudson/plugins/warnings/parser/ParserRegistry.java
http://jenkins-ci.org/commit/warnings-plugin/33eae6684567e8296a7c7030071833c5d58d0f77
Log:
[FIXED JENKINS-16526] Excessive work done in rendering.
Fixed by caching GroovyParser → AbstractWarningsParser.
Code changed in jenkins
User: Ulli Hafner
Path:
src/main/java/hudson/plugins/warnings/GroovyParser.java
src/main/java/hudson/plugins/warnings/parser/ParserRegistry.java
http://jenkins-ci.org/commit/warnings-plugin/d677b1f5d9f15275884b17cb705c032ac74eae47
Log:
Merge pull request #15 from jglick/JENKINS-16526
[FIXED JENKINS-16526] [FIXED JENKINS-16107] Cache parsers after creation.
Compare: https://github.com/jenkinsci/warnings-plugin/compare/6a770de735b1...d677b1f5d9f1
–
You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Hardly related, but I added a comment to: https://github.com/jenkinsci/warnings-plugin/commit/b416ca53c57a8bab3f4e5e5bb61279f030d3da20