Status: Closed (View Workflow)
6.3.9, 6.4.14, 7.2.10, 7.3.8, 7.4.1, 7.5.1, 7.6.9
Severity 1 - Critical
Atlassian Update - 2 September 2019 Dear users, Createmeta REST endpoint is commonly used when Atlassian products (Confluence, Bitbucket, and others) create issues in Jira. It might also be used by 3rd party apps. The main problem with the old createmeta endpoint is that it is duplicating values in the response. Although the response can be filtered, due to the design of the endpoint it is very easy to cause downtime. We have been working on a fix for this problem most of the solutions made the endpoint harder and more complex to use. So we decided to deprecate the old endpoint and introduce new endpoints that will replace the old createmeta endpoint. We also added a new dark feature to disable the old endpoint. The new endpoints will return projects, issue types and fields separately. You can find more details here . Changes will be released with Jira 8.4.0 and the old createmeta will be removed in Jira 9. We suggest anyone who is using the old endpoint to migrate to the new endpoints. Since this endpoint is used by other Atlassian products, they will be updated also. We are planning the changes and we will update this ticket with the compatible version of each product. Sincerely, Celebi Murat Jira Server Development
Executing requests to /jira/rest/api/2/issue/createmeta?params on larger instances can take over a minute to complete and generate large content (500MB+). In some cases JIRA can run out of memory or have heavy GC pressure. At this stage we believe there are 2 possible problems:
- In case of standard requests with projects.issuetypes parameters, problem is caused by duplicated data for issue-types, see Duplicate content below for details.
- With fields added (createmeta?projects.issuetypes.fields), it's more likely that JIRA can run out of memory. The main problem is that objects representing either issue types or custom fields are not reused among projects. So theoretically this issue could be reproduced with one multi-select custom field with thousands of values and a thousand of projects.
The following data exists in the test instance:
And 323 issue types.
Having instance with multi-select CF with large number of values magnifies the problem.
So problem is a multiplication of factors:
- Number of CustomFields values x Number of IssueTypes x Number of Projects having that
- Setup or use an instance with similar data sizes.
- Query /rest/api/2/issue/createmeta?projects.issuetypes, for example https://jira.atlassian.com/rest/api/2/issue/createmeta?projects.issuetypes.
The query returns in a reasonable timeframe. No JVM memory pressure.
The query takes ~60 secs as per the attached screenshot, or in some cases runs out of memory entirely.
We decided to remove this endpoint in Jira 9.0 see Createmeta REST endpoint to be removed
We have seen that in some cases there are logical duplicates in the optionconfiguration table. This, depending on the number of affected issue types, can cause performance issues itself. To check for such, you can run the following query:
If the above returns any rows, you are likely affected by the problem. In this case, please raise a ticket on https://support.atlassian.com, referring to this bug report and ask for assistance on de-duplicating the table.
See related JRASERVER-66306
- Block the call to REST API at proxy level
- Any integration using this API will be affected, (eg: create JIRA issue from Confluence will not work)
- Increasing the heap could be strategy for small heaps (< 10GB)
REST createmeta will show all data to create issue, so you remove the CF from screen it will be not present in the payload for that specific issues.
- If possible, delete unused CustomFields and/or CustomFields values.
- Make CustomFields more specific:
- Choose applicable issue types
- Choose applicable context (Project)
- Remove the CustomFields from screen which are not require it.
- Make CustomFields more specific: