[JENKINS-16526] Numerous uncached calls to ParserRegistry.getAllParsers

Type: Bug
Resolution: Fixed
Priority: Major
Component/s: warnings-plugin
Labels:
- performance

Similar Issues:
Powered by SuggestiMate

Show

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.)

- - Sort By Name
  - Sort By Date
  - Ascending
  - Descending
  - Thumbnails
  - List
  - Download All

warnings-snafu.txt
81 kB
2013-01-29 18:59

is duplicated by

JENKINS-16107 Warnings plugin with custom parsers massively slows down jenkins start up

Resolved

Jesse Glick created issue - 2013-01-29 18:59

Jesse Glick made changes - 2013-01-29 19:00

Description

Original: 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:

{code:none}
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...
{code}

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.)

New: 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:

{code:none}
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...
{code}

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

{code:none}
some/file:33:deprecation: you did not want to do this!
{code}

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.)

Jesse Glick made changes - 2013-01-29 21:35

Status

Original: Open [ 1 ]

New: In Progress [ 3 ]

Ulli Hafner made changes - 2013-01-31 09:26

Link

New: This issue is duplicated by ~~JENKINS-16107~~ [ ~~JENKINS-16107~~ ]

SCM/JIRA link daemon made changes - 2013-01-31 11:08

Resolution		New: Fixed [ 1 ]
Status	Original: In Progress [ 3 ]	New: Resolved [ 5 ]

R. Tyler Croy made changes - 2016-07-25 23:55

Workflow

Original: JNJira [ 147349 ]

New: JNJira + In-Review [ 192353 ]

Jenkins

Details

Description

Attachments

Attachments

Issue Links

Activity

People

Dates