SearchRequest.xml exports get stuck in aggregate time-tracking calculation DocumentIssueAggregateTimeTrackingCalculator.getAggregates

XMLWordPrintable

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Medium
    • None
    • Affects Version/s: 10.7.4
    • Component/s: JQL Search
    • None
    • 10.07
    • 3
    • Severity 2 - Major
    • 58

      A customer on Jira 10.7.4 DC is experiencing recurring, severe performance degradation and node-level unavailability. The root cause appears to be SearchRequest.xml export requests that become "stuck" during aggregate time-tracking calculation:

      com.atlassian.jira.issue.util.DocumentIssueAggregateTimeTrackingCalculator.getAggregates(...)
      

      For each issue in the SearchRequest.xml results, Jira always calls getAggregates(DocumentIssueAggregateTimeTrackingCalculator.java:70) in Issue XMLView, regardless of the requested fields.

      Tomcat thread dumps shows http worker threads stuck in TIMED_WAITING (parking) in LinkedBlockingQueue.poll(...) inside the aggregate calculation, sometimes for days:

      "http-nio-0.0.0.0-8080-exec-15 url: /sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml; user: abcd" #1870 [33522] daemon prio=5 os_prio=0 cpu=4348910.61ms elapsed=353158.82s tid=0x00007f5cef47fa60 nid=33522 runnable  [0x00007f588e1d6000]
         java.lang.Thread.State: TIMED_WAITING (parking)
      	at jdk.internal.misc.Unsafe.park(java.base@21.0.9/Native Method)
      	- parking to wait for  <0x00000004783436e8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
      	"http-nio-0.0.0.0-8080-exec-20 url: /sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml; user: dcba" #1875 [33527] daemon prio=5 os_prio=0 cpu=4352227.79ms elapsed=353158.82s tid=0x00007f5ceda11f10 nid=33527 runnable  [0x00007f588f0e5000]
         java.lang.Thread.State: RUNNABLE
      	at java.lang.Thread.start0(java.base@21.0.9/Native Method)
      	at java.lang.Thread.start(java.base@21.0.9/Thread.java:1553)
      	- locked <0x0000000478d0d720> (a java.lang.Thread)
      	at java.lang.System$2.start(java.base@21.0.9/System.java:2577)
      

      This leads to progressive exhaustion of available workers and node-level degradation which can only be recovered with restart of nodes.

      Additionally, there is a FR in Confluence https://jira.atlassian.com/browse/CONFSERVER-98578 which covers impact on Jira performance if in case "field=allcustom".

      Workaround:
      Restarting the affected node is currently the only reliable way to clear the stuck threads and restore normal behaviour.

              Assignee:
              Unassigned
              Reporter:
              skavatekar
              Votes:
              9 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated: