Its still possible for JIRA Agile's upgrade tasks to create duplicated LexoRank fields, and this is causing re-indexing to fail with the following errors:

      java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.RuntimeException: Expected exactly 2 rows; the maximum marker row and the lowest ranked row for rank field[id=10300]
          at com.atlassian.jira.index.FutureResult.await(FutureResult.java:35)
          at com.atlassian.jira.index.CompositeResultBuilder$CompositeResult.await(CompositeResultBuilder.java:82)
          at com.atlassian.jira.issue.index.DefaultIndexManager.doIndexIssuesInBatchMode(DefaultIndexManager.java:857)
          at com.atlassian.jira.issue.index.DefaultIndexManager.doStopTheWorldReindex(DefaultIndexManager.java:827)
          at com.atlassian.jira.issue.index.DefaultIndexManager.reIndexAll(DefaultIndexManager.java:337)
          ...
      Caused by: java.util.concurrent.ExecutionException: java.lang.RuntimeException: Expected exactly 2 rows; the maximum marker row and the lowest ranked row for rank field[id=10300]
          at java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source)
          at java.util.concurrent.FutureTask.get(Unknown Source)
          at com.atlassian.jira.index.FutureResult.await(FutureResult.java:31)
          ... 25 more
      Caused by: java.lang.RuntimeException: Expected exactly 2 rows; the maximum marker row and the lowest ranked row for rank field[id=10300]
          at com.atlassian.greenhopper.manager.lexorank.LexoRankDaoImpl.getMaximumMarkerRowAndPreviousRow(LexoRankDaoImpl.java:393)
          at com.atlassian.greenhopper.service.lexorank.LexoRankOperation.rankInitially(LexoRankOperation.java:169)
          at com.atlassian.greenhopper.service.lexorank.LexoRankOperation.execute(LexoRankOperation.java:111)
          at com.atlassian.greenhopper.service.lexorank.LexoRankService.performRankOperation(LexoRankService.java:239)
          ...
          at com.atlassian.greenhopper.customfield.lexorank.LexoRankIndexer.getLexoRankValue(LexoRankIndexer.java:72)
          at com.atlassian.greenhopper.customfield.lexorank.LexoRankIndexer.getIndexValue(LexoRankIndexer.java:65)
          at com.atlassian.greenhopper.customfield.lexorank.LexoRankIndexer.addDocumentFields(LexoRankIndexer.java:51)
          at com.atlassian.greenhopper.customfield.lexorank.LexoRankIndexer.addDocumentFieldsSearchable(LexoRankIndexer.java:39)
      

      It is currently unknown how JIRA Agile is creating these duplicated rank fields. You can easily identify this by navigating to Administration >> Issues >> Custom Fields, check if there are multiple Rank custom fields of type Global Rank. (Not obsolete)

      When you have multiple rank fields, JIRA may be using the wrong Rank field while indexing issues. (The rank field that was not used in the balancing) So while indexing JIRA fails to find the maximum marker and minimum row.

      A KB has been created describing this in detail: https://confluence.atlassian.com/display/AGILEKB/Cannot+reindex+jira+due+to+Expected+exactly+2+rows+the+maximum+marker+row+and+the+lowest+ranked+row+for+rank+field

          Form Name

            [JSWSERVER-10985] Duplicated LexoRank fields causes indexing in JIRA to fail

            MattS added a comment -

            https://jira.atlassian.com/browse/GHS-10872 has lots more info about Lexorank mapping task and how to see what is happening

            MattS added a comment - https://jira.atlassian.com/browse/GHS-10872 has lots more info about Lexorank mapping task and how to see what is happening

            MattS added a comment -

            The JIRA Agile 6.6 release notes now contain a note recommending not to use Agile 6.4., 6.5 or 6.6 with large instances of JIRA.
            The linked KB article contains more details about how to detect and correct multiple Global Rank fields

            MattS added a comment - The JIRA Agile 6.6 release notes now contain a note recommending not to use Agile 6.4., 6.5 or 6.6 with large instances of JIRA. The linked KB article contains more details about how to detect and correct multiple Global Rank fields

            Eric added a comment -

            After further investigation by our development team, we have discovered that duplicated LexoRank fields does not necessarily cause indexing in JIRA to fail. However, having multiple LexoRank fields will slow down indexing as we have to process more fields.

            We further discovered that duplicated LexoRank fields can be caused by failed attempts to upgrade to JIRA Agile 6.4 or later. If your upgrade attempt fails, please make sure you roll back your data to the snapshot taken before the upgrade.

            Eric added a comment - After further investigation by our development team, we have discovered that duplicated LexoRank fields does not necessarily cause indexing in JIRA to fail. However, having multiple LexoRank fields will slow down indexing as we have to process more fields. We further discovered that duplicated LexoRank fields can be caused by failed attempts to upgrade to JIRA Agile 6.4 or later. If your upgrade attempt fails, please make sure you roll back your data to the snapshot taken before the upgrade.

            After opening a support ticket, it was determined that our problem was caused by having a duplicate Rank customfield from a failed upgrade. A couple of weeks ago, while we were troubleshooting a different issue, we attempted to upgrade Agile from 6.3.9.2 to 6.5. The upgrade failed. Without a time-stamp for when the field was created, we can't be 100% certain that it came from the failed upgrade, but we couldn't find any other reason that would have caused it to show up. Solution #2 from the KB article mentioned above worked for us and the re-index completed successfully.

            Chris Solgat added a comment - After opening a support ticket, it was determined that our problem was caused by having a duplicate Rank customfield from a failed upgrade. A couple of weeks ago, while we were troubleshooting a different issue, we attempted to upgrade Agile from 6.3.9.2 to 6.5. The upgrade failed. Without a time-stamp for when the field was created, we can't be 100% certain that it came from the failed upgrade, but we couldn't find any other reason that would have caused it to show up. Solution #2 from the KB article mentioned above worked for us and the re-index completed successfully.

            I have just encountered this problem while attempting to upgrade to jira agile 6.6. I was using the UI for this process. I clicked on the update button for Jira Agile. It downloaded fine, but did not initialize within 60 seconds. I made a second attempt at enabling the plugin, but had the same results. I then performed a system restart. During the system startup, the agile plugin initialized and then proceeded to run the upgrade tasks. The logs showed that the rank field was migrated successfully, but when it tried to reindex, this error appeared. The install did finish successfully. In researching, the ranks appear to be correct, but they are under a second customfield. Somewhere during this process, it created the new Rank custom field twice (customfield21800 and customfield21900). I don't see any entries in the logs showing where it created the new fields.

            Chris Solgat added a comment - I have just encountered this problem while attempting to upgrade to jira agile 6.6. I was using the UI for this process. I clicked on the update button for Jira Agile. It downloaded fine, but did not initialize within 60 seconds. I made a second attempt at enabling the plugin, but had the same results. I then performed a system restart. During the system startup, the agile plugin initialized and then proceeded to run the upgrade tasks. The logs showed that the rank field was migrated successfully, but when it tried to reindex, this error appeared. The install did finish successfully. In researching, the ranks appear to be correct, but they are under a second customfield. Somewhere during this process, it created the new Rank custom field twice (customfield21800 and customfield21900). I don't see any entries in the logs showing where it created the new fields.

              Unassigned Unassigned
              dleng Daniel Leng (Inactive)
              Affected customers:
              0 This affects my team
              Watchers:
              10 Start watching this issue

                Created:
                Updated:
                Resolved: