Uploaded image for project: 'Jira Software Data Center'
  1. Jira Software Data Center
  2. JSWSERVER-20691

Lexorank affects issue creation time

XMLWordPrintable

    • 8
    • 42
    • Severity 2 - Major
    • 11
    • Hide
      Atlassian Update – 11 June 2024

      Dear Customers,

      Thank you for taking the time to file and comment on this issue. We realize it still occurs and impacts your organization. We are now working on multiple customer requests and on new features, so we have to postpone our resolution of this issue. We’ve decided to move this issue to our long-term backlog.

      Please continue watching this ticket for future updates and changes in the timeline that impacts your work.

      Best regards

      Dino Costantini
      Principal Software Engineer

      Show
      Atlassian Update – 11 June 2024 Dear Customers, Thank you for taking the time to file and comment on this issue. We realize it still occurs and impacts your organization. We are now working on multiple customer requests and on new features, so we have to postpone our resolution of this issue. We’ve decided to move this issue to our long-term backlog. Please continue watching this ticket for future updates and changes in the timeline that impacts your work. Best regards Dino Costantini Principal Software Engineer

      Generating the initial lexorank can seriously affect issue creation time.

      This problem can be observed in 2 ways:

      1. contention on lexorank lock when initialising rank when creating issue
      2. some nodes are never able to get the lexorank lock and create the lexorank initial value

      Problem 1

      This problem will manifests itself by increased issue creation time. 

      In logs we need to enable DEBUG logging on com.atlassian.greenhopper.service.lexorank.

      The failed locks should show up in the atlassian-greenhopper.log log.

      DEBUG Failed to acquire a lock on the max marker row and previous row for rank field

      The indexing stats (indexing-stats) should also show the Rank custom field as expensive - note the max value as the lower value of the average may be "improved" by the updates which will not trigger the expensive Lexorank initialization.

      cat ./atlassian-jira.log | grep indexing-stats | grep total

INFO      [c.a.j.issue.index.IndexingStatsManager] [indexing-stats] Top 10 addIndex total... {order:1, name:customfield_15080 (Rank), isKnown:false, addIndex: {sum:1728649386ms, avg:1765.5ms, max:7199ms, count:979152} ...
      • Note: avg: 1765.5ms, max: 7199ms

      Problem 2 

      This problem will manifests itself by increased issue creation time in the range of 18-20sec.

      Lexorank is unable to get the lexorank lock (and create the lexorank initial value) and the issue is indexed with Lexorank.MAX. 

      This will be seen in the atlassian-greenhopper.log log as warnings:

      WARN [greenhopper.customfield.lexorank.LexoRankCFType] Unable to retrieve rank for field [10005] and issue [2010933]
WARN [greenhopper.customfield.lexorank.LexoRankCFType] gh.lexorank.service.error.retrytimeout
WARN [greenhopper.customfield.lexorank.LexoRankIndexer] Could not retrieve LexoRank value for issue[id=2010933]. Indexing max LexoRank value instead.

      Notes

      • Individual ranking operation has 1500 ms timeout for rank lock. Due to DB contetion and slow operation, issue ranking operation fails to save new rank since rank lock expire.
      • See KB for more details regarding Lexorank: Troubleshooting New Ranking System Issues

      Workaround

      Currently there is no known workaround for this behavior. A workaround will be added here when available

            a9ec86424806 Dino Costantini
            mswinarski Maciej Swinarski (Inactive)
            Votes:
            31 Vote for this issue
            Watchers:
            47 Start watching this issue

              Created:
              Updated: