-
Bug
-
Resolution: Fixed
-
Critical
-
* Jenkins running on a Linux server
* Majority of the jobs use the warnings plugin, but only some of them use the custom parsers
* Warnings plugin version: 4.18
* Jenkins version: 1.493
java -version:
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
* Jenkins running on a Linux server * Majority of the jobs use the warnings plugin, but only some of them use the custom parsers * Warnings plugin version: 4.18 * Jenkins version: 1.493 java -version: java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
Having specified custom parsers in the general jenkins configuration results in a massive slow down of the start up procedure of our jenkins server. Instead of a few seconds the startup takes probably longer than 20 minutes.
We have attached a visualvm to the JVM running jenkins and found out that the reason for the massive slow down is that the threads loading the jobs on startup are most of the time in the BLOCKED state. A thread dump is attached. All blocked threads basiclaly hang in the compilation of the defined custom parsers using groovy. Strangely, even jobs which use the warnings plugin, but not the custom parsers seem to invoke a compilation of the custom parsers and it also seems the the compiled parsers aren't shared between jobs at all, so each custom parsers is compiled for each job.
- duplicates
-
JENKINS-16526 Numerous uncached calls to ParserRegistry.getAllParsers
- Resolved
- is duplicated by
-
JENKINS-16037 Custom parsers in Warnings plugin still significantly slow down Jenkins Web interface
- Resolved