-
Bug
-
Resolution: Fixed
-
Highest (View bug fix roadmap)
-
6.4.1, 7.3.3, 7.0.0, 8.5.1, 8.13.10, 8.20.3
-
6.04
-
55
-
Severity 2 - Major
-
136
-
-
JIRA issue update via rest on cold caches may take significant amount of time (15 min on a customer instance). Subsequent issue updates take reasonable amount of time (~30 seconds).
Environment
Many values in custom fields options:
select count(cfo.id),customfield.cfname from customfieldoption cfo join customfield on customfield.id=cfo.customfield group by customfield.cfname order by count(cfo.id) DESC limit 10;
Steps to reproduce
- Create a MulitSelect custom field
- Add many values to it (e.g. 1000 or 10'000).
- Add the MultiSelect custom field to the project screens (to be able to set it for an issue).
- Restart JIRA
- Query issue update via rest.
- Enable SQL logging
Result
Issue update executes 1000 (or 10'000) requests to the database (see in SQL log). One per each value of a multi select.
Expected Result for Select
We execute only single SQL query as MulitSelect or Select can not have nested values.
Expected Result for CascadingSelect
We execute requests in batches, effectively reducing the numbers we query the database.
The root of the problem
Upon update operations, Multi Select loads all the data to validate the update. It browses all the fields that are defined for the issue and is checking whether we attempting to set any illegal value to a field.
The code to load Multi Select List and Cascading Select List is shared. Actually sharing the code makes loading of values sub-optimal for a Multi Select List.
In Multi Select List - for each of the values, we verify whether we have any nested options, it's actually impossible to have ones for a Multi Select List (but is possible for Cascading Select List).
It means that if we have a number N of Mulit Select Lists on a page with a number of Values V we will end up
N*V queries to the database to warm up the cache.
Ideas on how to fix it:
- Make a single query to DB/Cache to get the batch result for the children count, to evict values with no children. This should statistically make it faster.
- Pass some context in the CustomFieldOptionJsonBean so it will not attempt to query children to Multi Select List (as it can not have nested values, i.e. no children size is always 0).
- Eliminate code sharing between Multi Select List and Cascading Select List, for Multi Select List to load it's values in efficient way.
- causes
-
-
- Closed
-
-
JRASERVER-77920 Add support for binary collations in Microsoft SQL Server
- Gathering Interest
- is related to
-
-
- Closed
-
-
RAID-240 You do not have permission to view this issue
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Gathering Impact
-
-
-
- Gathering Impact
-
-
PS-1132 Loading...
- is mentioned by
-
- mentioned in
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[JRASERVER-44588] Multi Select/ Cascading Select List Custom Field loads options in a suboptimal way
Could you update the Current Status text to align with this being "Fixed"?
Dear Customers,
Thank you for taking the time to file and comment on this issue. We realize it still occurs and impacts your organization. We are now working on multiple customer requests and on new features, so we have to postpone our resolution of this issue. We’ve decided to move this issue to our long-term backlog.
Please continue watching this ticket for future updates and changes in the timeline that impacts your work.
Best regards
Daniel Dudziak
Senior Software Engineer
Let me translate:
Atlassian
We can see this problem still occurs and impact your organisations. As of today, we can not prioritise it higher as we are working on other major issues but are moving it to our Long Term roadmap.
Please continue watching this ticket for future updates and changes in the timeline that impacts your work.
English
We know it's a problem, but we're not going to fix it.
Please continue to be naïve by submitting your votes on Bugs.
Thank you for taking the time to file and comment on this issue. Feedback like yours helps us release valuable Jira features that solve problems for the greater customer base. To that end, we aim to keep our issues up-to-date so they accurately reflect current customer needs.
We can see this problem still occurs and impact your organisations. As of today, we can not prioritise it higher as we are working on other major issues but are moving it to our Long Term roadmap.
Please continue watching this ticket for future updates and changes in the timeline that impacts your work.
Yes, the ScriptRunner approach is what we have used as well. Standard Jira select fields really don't seem to perform well past about 5,000 different options
We had this requirement where we needed to load more than 15k options and allow it to grow 2 to 3 times. We tried various things like adding a JS in the description to allow search and then select2 add-on but none of those solutions worked with 15k options.
We solved this issue with this approach - Instead of a drop down, we created a project and a new issue type and added all 14k options as new issues in that project. Now we are using a multi issue picker field provided by ScriptRunner add-on and it works like a charm and can scale easily.
regards,
Vishal
Hi ialexeyenko could you please complete this issue with the steps to reproduce the bug, stacktraces, and further investigation. Thanks! cc/ ohernandez@atlassian.com
Any update reg. backport to 9.12.x LTS?