-
Bug
-
Resolution: Fixed
-
Major
A user of ParameterFilter had an unresponsive UI; the thread dump revealed several HTTP handling threads (e.g. GET /) busy as follows:
at hudson.views.ParameterFilter.matchesRun(ParameterFilter.java:142) at hudson.views.ParameterFilter.matchesBuildValue(ParameterFilter.java:129) at hudson.views.ParameterFilter.matches(ParameterFilter.java:97) at hudson.views.AbstractIncludeExcludeJobFilter.doFilter(AbstractIncludeExcludeJobFilter.java:68) at hudson.views.AbstractIncludeExcludeJobFilter.filter(AbstractIncludeExcludeJobFilter.java:57) at hudson.model.ListView.getItems(ListView.java:170)
While I am not sure whether matchAllBuilds was set in this case, inspecting the code of matchesBuildValue shows that it could be quite expensive when run against a job with hundreds or thousands of build records. This is doubly true in Jenkins 1.485+ where build records are lazily loaded, so doing a search like this could cause a great deal of activity to occur loading build.xml from disk, increasing memory as well—and soft reference eviction could mean that this needs to be done repeatedly.
Would be better for matchAllBuilds to be replaced with an int limit >= 1, so that users could put a cap on how many builds would be consulted before giving up.
It may also be useful to cache information about matches, since parameters of build records should be immutable once the build is complete.
Code changed in jenkins
User: jacob_robertson
Path:
src/main/java/hudson/views/MostRecentJobsFilter.java
src/main/java/hudson/views/ParameterFilter.java
src/main/java/hudson/views/RegExJobFilter.java
src/main/resources/hudson/views/MostRecentJobsFilter/config.jelly
src/main/resources/hudson/views/ParameterFilter/config.jelly
src/main/resources/hudson/views/RegExJobFilter/config.jelly
src/test/java/hudson/views/ParameterFilterTest.java
http://jenkins-ci.org/commit/view-job-filters-plugin/b10005a320585ed2fa03d6b06064fdb53fa0019c
Log:
fixed
JENKINS-18386,JENKINS-17597,JENKINS-17093,JENKINS-18399