-
Bug
-
Resolution: Fixed
-
Low
-
6.3.15, 6.4.1, 6.4.13, 6.4.14, 7.0.9
-
6.03
-
7
-
Severity 2 - Major
-
10
-
Summary
Performing a FixVersion = XYZ or AffectVersion = XYZ search without a project is very slow on instances with a lot of versions.
JIRA tries to load and show all unarchived versions in all visible to user projects.
Environment
- Tested on JIRA 7.0.9 and 6.4.13
- ~20,000+ versions
- ~600+ projects
Steps to Reproduce
- Open JQL search link on fixVersion in a new tab
Expected Results
It executes fast
Actual Results
It takes 28 seconds, at some large instances it can take minutes.
Thread dump shows thread busy doing filterVersions in getAllVersionsForProjects method:
"http-bio-8080-exec-10" #157 daemon prio=5 os_prio=0 tid=0x00007f4b680c3000 nid=0x3c7 runnable [0x00007f4fedb78000] java.lang.Thread.State: RUNNABLE at com.google.common.collect.Iterators$5.hasNext(Iterators.java:543) at com.google.common.collect.Iterators$5.hasNext(Iterators.java:543) at com.google.common.collect.Iterators$5.hasNext(Iterators.java:543) <repeated 180 times...> at com.google.common.collect.Iterators$5.hasNext(Iterators.java:543) at com.google.common.collect.Iterators$5.next(Iterators.java:550) at com.google.common.collect.Iterators$5.next(Iterators.java:554) .... at com.google.common.collect.Iterators$5.next(Iterators.java:554) at com.google.common.collect.Iterators$7.computeNext(Iterators.java:648) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at com.google.common.collect.Lists.newArrayList(Lists.java:138) at com.google.common.collect.Lists.newArrayList(Lists.java:119) at com.atlassian.jira.project.version.DefaultVersionManager.filterVersions(DefaultVersionManager.java:522) at com.atlassian.jira.project.version.DefaultVersionManager.getAllVersionsForProjects(DefaultVersionManager.java:674) at com.atlassian.jira.issue.search.searchers.renderer.AbstractVersionRenderer.getValidOptions(AbstractVersionRenderer.java:150) at com.atlassian.jira.issue.search.searchers.renderer.AbstractVersionRenderer.getValidOptions(AbstractVersionRenderer.java:37) at com.atlassian.jira.issue.search.searchers.renderer.AbstractProjectConstantsRenderer.getOptions(AbstractProjectConstantsRenderer.java:122) at com.atlassian.jira.issue.search.searchers.renderer.AbstractProjectConstantsRenderer.addEditParameters(AbstractProjectConstantsRenderer.java:114) at com.atlassian.jira.issue.search.searchers.renderer.AbstractProjectConstantsRenderer.getEditHtml(AbstractProjectConstantsRenderer.java:102) at com.atlassian.jira.components.query.DefaultSearcherService.getEditHtml(DefaultSearcherService.java:473) at com.atlassian.jira.components.query.DefaultSearcherService.getValueResults(DefaultSearcherService.java:259) at com.atlassian.jira.components.query.DefaultSearcherService.getSearchResults(DefaultSearcherService.java:180) at com.atlassian.jira.components.query.DefaultSearcherService.searchWithJql(DefaultSearcherService.java:174) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ...
Notes
- It seems to cache something locally because if you hit the search button, it comes back fast. But if you reload the page, it takes 28 seconds.
- Scope of the problem: when searchRenderer is implementing AbstractVersionRenderer, eg. AffectedVersionRenderer , FixForVersionRenderer, VersionPickerCustomFieldRenderer:
Workaround
Use project in JQL search
- is related to
-
JSWSERVER-13355 The new Release page in JIRA 7 doesn't perform well on large instances
- Closed
-
RUM-191 Loading...
- relates to
-
JRASERVER-65087 Expensive JQL When Comparing Versions
- Closed
-
JRASERVER-66053 Loading values into version picker on basic issue search is very slow
- Closed