Jira DC High Heap Memory Consumption Caused by Xray REST API Responses

Customer came to us stating that they are experiencing significant heap memory consumption in their Jira Data Center environment, leading to JVM memory pressure and potential service instability.

The OOM is primarily caused by Xray's search implementation, particularly the use of PagerFilter.getUnlimitedFilter() in multiple search operations.

Primary finding – /rest/raven/1.0/issue/search

Jira 11-specific memory issue

The Jira 11 IssueSearcherImpl implementation does not specify fieldsToLoad() when constructing the search request. Unlike the Jira 9/10 implementation, which retrieves only the issue key, the inspected Jira 11 implementation appears to retrieve complete indexed documents for every matching issue.

The Atlassian stack trace (TopFieldCollector.create → FieldValueHitQueue.create → PriorityQueue.<init>) is consistent with the memory allocation pattern of a large, sorted Lucene search.

Other contributing areas identified:

Cucumber import: TestImportServiceImpl and IssueSearchByFieldServiceImpl perform unlimited searches for Test and Precondition lookups. The summary-based lookup retrieves and sorts all matching issues before filtering for an exact match.

JQL functions: TestExecutionTests Function loads complete Issue objects to validate issue types, while TestSetTestsFunction collects Test IDs without eliminating duplicates.

Background processing: XrayThreadPoolExecutorImpl uses Executors.newFixedThreadPool(), which has an unbounded queue. Additionally, Jira thread-local/request-cache lifecycle management appears to be missing, potentially contributing to memory retention.

Test Repository: The Load All operation retrieves all Tests using an unlimited search and processes their descriptions, adding further memory overhead.

Conclusion: The unlimited search in IssueSearchResource, amplified by the Jira 11 wrapper's retrieval of complete indexed documents, is the strongest identified explanation for the OOM.

Workaround
Partial workaround available

There is no complete workaround because the unlimited search behavior is implemented at the code level, and no server-side configuration has been identified to limit the affected endpoint.

However, the following steps can help reduce memory consumption until a permanent fix is available:

Restrict JQL to a specific project

Users accessing the Existing Tests tab should avoid broad searches across the entire Jira instance.

Instead of:

issueType = Test

Use:

project = HWCDOE AND issueType = Test

Apply additional filters wherever possible to reduce the number of matching Tests.

Avoid broad saved filters

Review JQL queries using testExecutionTests("<filter>") and avoid saved filters that return large numbers of Test Executions. Prefer specific Test Execution keys wherever possible.

Avoid large Cucumber imports during peak hours

• Split large feature files into smaller imports.

• Prefer explicit issue-key references (e.g. @PROJ-123) where supported.

• Avoid unnecessary summary-based lookups.

Avoid Load All in the Test Repository

Load only the required folders and Tests instead of retrieving the entire repository.

Limitation: These are temporary mitigations only. They reduce the number of records processed but do not eliminate the underlying unlimited search or Jira 11 memory overhead.

Permanent resolution requires code changes, primarily in IssueSearchResource and the Jira 11 wrapper.