Introducing safeguards to Jira index
プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Fisheye および Crucible は除く
課題関連のエンティティのインデックス作成を改善
Check What's changed in Jira after the implementation of indexing limits for common questions related to indexing limits and differences in the way Jira works since the update.
JRASERVER-73874 - Getting issue details... STATUS
Starting from 8.22.2 (backported to 8.20.12), Jira will index only topN
of the following issue-related entities: comments, changehistory, and worklog. Any reindexing operation that triggers full issue reindex, including full foreground reindex and indexer#reindex(issue, all), will reindex a limited number of topN
of related entities. The topN
value can be any integer.
This feature is enabled by default with the following limits set to related entities (comments, changehistory, and worklog):
Jira バージョン | Limit for comments | Limit for changehistory | Limit for worklog |
---|---|---|---|
8.20.11 | N/A | N/A | N/A |
8.20.12 | 500 | 100 | 100 |
8.22.1 | N/A | N/A | N/A |
8.22.2 | 1000 | 1000 | 1000 |
8.22.3 | 1000 | 1000 | 1000 |
8.22.4 | 500 | 100 | 100 |
9.0.0 以降 | 500 | 100 | 100 |
Based on specific use cases, Jira admins can change the default topN
values for these entities by setting a Java property to the desired limit. System property names for issue entities:
- For comments:
jira.safeguards.indexing.issue.comments
- For change history items:
jira.safeguards.indexing.issue.changelogs
- For worklogs:
jira.safeguards.indexing.issue.worklogs
It’s also possible to disable the feature by setting the corresponding system property to -1.
For example on how to change one of these properties, please refer to the KB article How to change Indexing Limit Safeguards in Jira.
As part of the feature, we’ve added stats to help you gather information about the indexing of issue-related entities. You can find more details here: Jira indexing-limits stats.
Introducing limits to change items indexing
Jira 8.22.3 also introduces updates to the way indexing works. In this release, we’ve extended the functionality of Safeguards in Jira index that changes the default behavior of change items indexing.
Change items with unsupported fields will be filtered out before they’re collected into change groups. As a result, when there’s a group of change items with unsupported fields only, it won’t be indexed. So, no document will be created for it in the database. That means, any changes on all other fields except the ones below will not be searchable.
These are the only fields that will be in the change items index and searchable:
Assignee
Fix Version
Priority
Reporter
Resolution
Status
In specific use cases, Jira administrators can change the default behavior. For example, when there’s a need to use the UpdatedBy JQL function, Jira administrator can configure the following system property. If this parameter is set to true, all fields will be indexed and they will be searchable:
jira.safeguards.indexing.issue.changelogs.do.not.filter.out.unsupported.fields
Consider the following:
- If this system property isn’t setup, change items with unsupported fields will be filtered out, which means the fields (except above 6 of them) will not be found via a JQL search. This is the default behavior.
- If this system property is set to "true", unsupported fields won’t be filtered out and all the fields will be searchable.
- The number of indexed change groups will be limited to
DEFAULT_INDEXING_LIMIT
. - To enable the old search functionality for historical changes, use the mentioned system property along with
jira.safeguards.indexing.issue.changelogs
(it defines how many groups should be indexed).
If unsupported fields aren’t filtered out, this may cause performance degradation for large issues. You can identify issues with large change items and change groups by running a database query. For details, see Retrieve issue change history from database in Jira server.