Bulk editing more than 10000 issues will result in XSRF Security Token Missing

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.

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.

*Except Fisheye and Crucible

Bulk editing 10000 issues will cause severe performance degradation if it is not planned cautiously. Please proceed with caution and also make sure you have tested the bulk edit action on a smaller issue count.

To be accurate, it's not 10000 issues:

  • 9996 issues - bulk edit operation works fine.
  • 9997 issues - bulk edit operation will result in XSRF Security Token Missing.

Problem

While it is not recommended to perform a bulk operation for more than 1000 issues - this is to avoid performance issues on a JIRA instance, sometimes we would like to bulk edit or bulk edit issues on a test/development instance.

  1. We can increase the bulk edit issue limit as per the KB article in How do you increase the bulk change maximum?.
  2. Bulk edit operation will hit XSRF Security Token Missing if we edit more than 9997 issues, even after setting the jira.bulk.edit.limit.issue.count to 10000. 

Diagnose

In <install-folder>/logs/catalina.<date>.log, you can see maxParameterCount has exceeded the limit in a single request:

28-Jun-2022 09:05:13.293 INFO [https-jsse-nio-8443-exec-20] org.apache.tomcat.util.http.Parameters.processParameters More than the maximum number of request parameters (GET plus POST) for a single request ([10,000]) were detected. Any parameters beyond this limit have been ignored. To change this limit, set the maxParameterCount attribute on the Connector.

Cause

In Tomcat, the default value for maxParameterCount is 10000. It means Tomcat doesn't take more than 10000 parameters and when we bulk edit more than 9997 issues, the request is losing the token due to the limitation. More information can be found here; Apache Tomcat 8 Configuration Reference.

Resolution

Option 1: Export issues to smaller amounts such as 5k issues per export. 

Option 2: Increase the maxParameterCount limit via server.xml

  1. Stop JIRA.
  2. Edit server.xml to make sure the connector has the maxParameterCount configuration, for example: 

    For JIRA Software version 7.12.3 and above:

    <Connector port="8080"
                       maxThreads="150"
                       minSpareThreads="25"
                       connectionTimeout="20000"
                       enableLookups="false"
                       maxHttpHeaderSize="8192"
                       protocol="HTTP/1.1"
                       useBodyEncodingForURI="true"
                       acceptCount="100"
                       disableUploadTimeout="true"
                       relaxedPathChars="[]|" 
                       relaxedQueryChars="[]|{}^&#x5c;&#x60;&quot;&lt;&gt;"
                       maxParameterCount="10100" />

    For JIRA version lower than 7.12.3:

    <Connector port="8080"
                       maxThreads="150"
                       minSpareThreads="25"
                       connectionTimeout="20000"
                       enableLookups="false"
                       maxHttpHeaderSize="8192"
                       protocol="HTTP/1.1"
                       useBodyEncodingForURI="true"
                       acceptCount="100"
                       disableUploadTimeout="true"
                       maxParameterCount="10100" />

    (info) The trick is to always have maxParameterCount more by 100 of the jira.bulk.edit.limit.issue.count value to prevent any problem.

  3. Start JIRA.


Last modified on Jul 22, 2022

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.