Performance degradation in Jira 11.3 due to serializing application property reads

XMLWordPrintable

    • Type: Bug
    • Resolution: Unresolved
    • Priority: High
    • None
    • Affects Version/s: 10.4.0, 11.3.10, 11.3.11
    • Component/s: Java API
    • None
    • 10.04
    • 1
    • Severity 2 - Major

      Issue Summary

      In Jira 11.3.x, concurrent reads of application properties can block each other and slow down the whole Jira instance.

      Jira uses a component to choose how it reads application properties before and after database setup. For each property read, this component calls DatabaseConfigurationManagerImpl.isDatabaseSetup().

      This method takes the local setupLock and checks the database configuration. Only one thread can run this check at a time.

      The problem is most visible when code reads an application property many times. One example is the read-only mode check in permission checks. Jira 11.3 runs this check during issue, project, and project-wide permission checks.

      Read-only mode is only one trigger. It is not the root cause. Disabling read-only mode does not help because Jira still needs to read the property to check whether the mode is enabled.

      Steps to Reproduce

      1. Use Jira Data Center 11.3.x
      2. Run many operations at the same time that perform issue or project permission checks
        1. For example, run large JQL searches, Structure jobs, or Zephyr Scale imports or reports at the same time
      3. Collect 5 to 10 thread dumps, 10 seconds apart, while the workload is running
      4. Check the thread dumps for threads waiting in DatabaseConfigurationManagerImpl.isDatabaseSetup()

      Expected Results

      Concurrent application property reads do not block each other.

      Permission-heavy work does not cause lock-related delays across the Jira instance.

      Actual Results

      Application property reads can wait for DatabaseConfigurationManagerImpl.setupLock.

      When many threads read application properties at the same time, they wait for DatabaseConfigurationManagerImpl.isDatabaseSetup() to finish and execute the check one thread at a time.

      This can increase request time and cause Jira to become slow across the instance.

      Workaround

      • Stagger large 3rd-party app processing jobs instead of running them concurrently.
      • Reduce or reschedule operations that perform large project-wide or issue-wide permission enumerations.
      • Avoid running large permission-heavy background jobs during peak interactive usage.

              Assignee:
              Mateusz Beczek
              Reporter:
              Chris
              Votes:
              3 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated: