-
Bug
-
Resolution: Fixed
-
Highest
-
7.2.8, 7.4.5, 7.2.12, 7.5.3, 7.6.3, 7.3.9, 7.9.2, 7.6.7, 7.11.2, 7.13.1, 8.1.0
-
7.02
-
24
-
Severity 1 - Critical
-
194
-
-
Summary
Editing multiple different projects at the same time and assigning same IssueTypeSchema (ITS) to them, may cause data loss for other projects using same ITS. Those other projects (not the one that were changed) could be reverted to the default issue type scheme during the change due to race condition.
Steps to Reproduce
- Generate 2000 projects.
- Create a new issue type scheme, call it 'ITS A'.
- Associate 1800 projects with the newly created issue type scheme 'ITS A'.
- Jot down the number of total projects associated with the default issue type scheme (it should be 200).
- Update two of the projects associated with the default issue type scheme before with the newly created issue type scheme 'ITS A' simultaneously via Project settings > Issue types > Actions > Use a different scheme.
- Review the number of total projects associated with the default issue type scheme.
Expected Results
The number of total projects associated with the default issue type scheme is reduced by 2.
Actual Results
The number of total projects associated with the default issue type scheme increases by random number (more then 200).
Enabling DEBUG logging for com.atlassian.jira.issue.context.persistence will show number of deleted rows, snippet from atlassian-jira.log file:
2018-01-11 17:24:51,050 http-nio-8081-exec-13 DEBUG admin 1044x992x1 1mxuaim 127.0.0.1 /secure/admin/SelectIssueTypeSchemeForProject.jspa [c.a.j.i.context.persistence.FieldConfigContextPersisterWorker] 1 contexts deleted for field config scheme with id '11500' 2018-01-11 17:26:41,157 http-nio-8081-exec-13 DEBUG admin 1046x1017x1 1mxuaim 127.0.0.1 /secure/admin/SelectIssueTypeSchemeForProject.jspa [c.a.j.i.context.persistence.FieldConfigContextPersisterWorker] 0 contexts deleted for field config scheme with id '11700'
Notes
- There is a race-condition between deleting existing IssueTypeSchema for other projects and reading projects association.
- Pseudo-code:
- Thread1 reads valid project list, deletes it and re-creates it
// reads valid project list associatedProjects = configScheme.getAssociatedProjectObjects(); ... // deletes all projects with schema contextPersister.removeContextsForConfigScheme(newScheme); <-- Thread2 reads the partial project list --> // re-creates projects storeAssociatedContexts(configScheme, associatedProjects, field);
- Thread2 reads partial project list, deletes it and re-creates partial project list
associatedProjects = configScheme.getAssociatedProjectObjects(); ...
- Thread1 reads valid project list, deletes it and re-creates it
- Pseudo-code:
- Problem is easier to reproduce in Datacenter due to distributed scope and delay in cache propagation.
Workaround
- Since problems is a race condition, you can mitigate it by editing IssueTypeSchema for only one projects at the same time
- In worse case scenario to prevent the schema change, you may want to block URL /secure/admin/SelectIssueTypeSchemeForProject.jspa
Action for data recovery
- In simple scenario you can reassign corresponding IssueTypeSchema (ITS) to affected projects
- In case of large number projects affected, usually the list it's not that obvious. You will need JIRA DB backup (or staging copy).
- You will need a couple of tables (configurationcontext, project, fieldconfigscheme) and run the following SQL to get the mapping list:
select p.id as PID,p.pname as ProjectName,cc.fieldconfigscheme as ITS_ID,fcs.configname as ITS_Name from configurationcontext cc,project p,fieldconfigscheme fcs where cc.customfield = 'issuetype' and p.id=cc.project and fcs.id=cc.fieldconfigscheme; pid | projectname | its_id | its_name -------+--------------------+--------+---------------------------------------------- 10001 | Dragons | 10101 | DRA: Simple Issue Tracking Issue Type Scheme 10100 | PRG | 10300 | PRG: Simple Issue Tracking Issue Type Scheme 10300 | Agile-Project | 10805 | AG: Scrum Issue Type Scheme
- You will need a couple of tables (configurationcontext, project, fieldconfigscheme) and run the following SQL to get the mapping list:
- has a regression in
-
JRASERVER-68948 Regression: Projects may be reverted to the default issue type scheme during the change due to race condition
- Closed
- is related to
-
JRASERVER-66995 JIRA may cache wrong value config scheme due to race condition
- Gathering Impact
- relates to
-
JRASERVER-71998 If a failure is sustained while creating a project from shared configuration, Issue Type Schemes may be reverted to Default
- Closed
-
JRASERVER-71178 Concurrent invocation of updateFieldConfigScheme on FieldConfigSchemeManager may result in IssueTypeScheme and PriorityScheme to revert to default
- Closed
-
GRD-201 Loading...
-
GRD-235 Loading...
-
PSR-59 Loading...
-
PSR-308 Loading...
- Mentioned in
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...