Details
-
Bug
-
Resolution: Unresolved
-
Low
-
None
-
8.19.1, 8.20.8
-
None
-
8.19
-
1
-
Severity 2 - Major
-
2
-
Description
Issue Summary
Multiple endpoints trigger Jira to count and calculate archived issues, this includes Jira's Cluster Monitoring Service and the /status endpoint. This then impacts archiving functioning, causing archiving actions to be slow as it is bottlenecking the database.
Steps to Reproduce
- Set up a Jira DC cluster (also affects Jira Server)
- Populate it with issues and projects as described below, excerpted from a support zip
- Constantly request the /status endpoint (every 5 secs for eg)
- For some customers, the Cluster Monitoring Service alone is enough to impact their system.
- Perform a bulk archive operation
Expected Results
Archiving operations complete in a timely fashion
Actual Results
The bulk archive operation may take several hours to complete, making it difficult to maintain large systems.
The logs may show database transaction timeouts like this:
2022-05-06 09:23:59,572-0700 https-jsse-nio-443-exec-81 ERROR [o.a.c.c.C.[.[localhost].[/].[action]] Servlet.service() for servlet [action] in context with path [] threw exception [com.atlassian.jira.exception.DataAccessException:
org.ofbiz.core.entity.GenericEntityException: while updating: [GenericEntity:Issue][archived,N][id,58258][archivedby,null][updated,2017-03-26 15:05:24.0][archiveddate,null] (SQL Exception while executing the following:UPDATE jiraissue S
ET ARCHIVED=?, ARCHIVEDBY=?, ARCHIVEDDATE=? WHERE ID=? (Lock wait timeout exceeded; try restarting transaction))] with root cause
com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Lock wait timeout exceeded; try restarting transaction
...
at com.atlassian.jira.ofbiz.DefaultOfBizDelegator.storeAll(DefaultOfBizDelegator.java:257)
at com.atlassian.jira.ofbiz.WrappingOfBizDelegator.storeAll(WrappingOfBizDelegator.java:151)
at com.atlassian.jira.issue.util.DefaultIssueUpdater.storeModifiedFields(DefaultIssueUpdater.java:120)
at com.atlassian.jira.issue.util.DefaultIssueUpdater.doUpdate(DefaultIssueUpdater.java:94)
at com.atlassian.jira.issue.util.DefaultIssueUpdater.doUpdate(DefaultIssueUpdater.java:73)
at com.atlassian.jira.issue.managers.DefaultIssueArchiveHelper.update(DefaultIssueArchiveHelper.java:133)
at com.atlassian.jira.issue.managers.DefaultIssueArchiveHelper.restoreIssue(DefaultIssueArchiveHelper.java:192)
at com.atlassian.jira.issue.managers.DefaultIssueManager.restoreIssue(DefaultIssueManager.java:688)
at com.atlassian.jira.issue.managers.RequestCachingIssueManager.restoreIssue(RequestCachingIssueManager.java:234)
at com.atlassian.jira.issue.archiving.DefaultArchivedIssueService.updateIssue(DefaultArchivedIssueService.java:105)
at com.atlassian.jira.issue.archiving.DefaultArchivedIssueService.restoreIssue(DefaultArchivedIssueService.java:90)
at com.atlassian.jira.web.action.issue.RestoreIssue.doExecute(RestoreIssue.java:29)
... 1 filtered
Workaround
There is a workaround to disable archive checks when using the /status endpoint
Currently there are no workarounds for the Cluster Monitoring Service
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
ASCI-68 Loading...