Ranking failed due to LOCK_HASH is not null

Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.

Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. 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

Summary

Problem

When performing issue ranking in a board, we will see the following pop-up warning message:

1
2

JIRA Software cannot execute the rank operation. This board has recently been configured to use the Rank field. 
The system must be re-indexed before you can rank issues. Ask your administrator to perform a manual re-index.

The following appears in the atlassian-jira.log during project creation or other actions that trigger ranking operations:

2020-12-11 02:19:15,138 NodeReindexServiceThread:thread-1 DEBUG      [greenhopper.service.lexorank.LexoRankOperation] Failed to acquire a lock on the max marker row and previous row for rank field[id=xxxx], retrying rank intially
2020-12-11 02:19:15,138 NodeReindexServiceThread:thread-1 DEBUG      [greenhopper.service.lexorank.LexoRankOperation] RANK_INITIAL end   [fieldId=xxxx, issueToRankIssueId=xxxx, issueToRankAroundIssueId=null
2020-12-11 02:19:15,138 NodeReindexServiceThread:thread-1 WARN      [greenhopper.customfield.lexorank.LexoRankCFType] Unable to retrieve rank for field [xxxx] and issue [xxxxx]
2020-12-11 02:19:15,138 NodeReindexServiceThread:thread-1 WARN      [greenhopper.customfield.lexorank.LexoRankCFType] gh.lexorank.service.error.retrytimeout
2020-12-11 02:19:15,138 NodeReindexServiceThread:thread-1 WARN      [greenhopper.customfield.lexorank.LexoRankIndexer] Could not retrieve LexoRank value for issue[id=xxxxx]. Indexing max LexoRank value instead.

Alternatively, you may also see entries such as these:

2016-08-30 19:15:41,023 JiraTaskExectionThread-1 WARN localadmin 1154x139x1 xxx xx.xx.xx.xx /secure/admin/IndexReIndex.jspa [c.a.g.customfield.lexorank.LexoRankCFType] Unable to retrieve rank for field [xxxx] and issue [xxxxx]
2016-08-30 19:15:41,023 JiraTaskExectionThread-1 WARN localadmin 1154x139x1 xxx xx.xx.xx.xx /secure/admin/IndexReIndex.jspa [c.a.g.customfield.lexorank.LexoRankCFType] gh.lexorank.service.error.retrytimeout
2016-08-30 19:15:41,023 JiraTaskExectionThread-1 WARN localadmin 1154x139x1 xxx xx.xx.xx.xx /secure/admin/IndexReIndex.jspa [c.a.g.customfield.lexorank.LexoRankIndexer] Could not retrieve LexoRank value for issue[id=xxxxx]. Indexing max LexoRank value instead.
2016-08-30 19:15:41,038 JiraTaskExectionThread-1 DEBUG localadmin 1154x139x1 xxxx xx.xx.xx.xx /secure/admin/IndexReIndex.jspa [c.a.g.service.lexorank.LexoRankOperation] Failed to acquire a lock on the max marker row and previous row for rank field[id=xxx], retrying rank intially

Diagnosis

Enable Lexorank debugging packages below to DEBUG level:
1 2 3com.atlassian.greenhopper.service.lexorank.balance com.atlassian.greenhopper.service.lexorank com.atlassian.greenhopper.service.lexorank.LexoRankStatisticsAgent
Identify whether there are any issues with values other than "NULL" in "LOCK_HASH" column:
1SELECT COUNT("ID") FROM "AO_60DB71_LEXORANK" WHERE "LOCK_HASH" is NOT NULL AND "TYPE" in ('0','2');
ℹ️ In database engines different than PostgreSQL, remove the double-quotes (") from the query.
If the query results number is higher than 1, there are issues with LOCK_HASH value being other than NULL, thus you may proceed with the resolution steps from this article.

Cause

There are some issues in the AO_60DB71_LEXORANK table with a LOCK_HASH column value other than NULL.

This problem may be caused by different reasons like Jira crashing during a ranking operation, failures in the communication with the database, and also there were reports that the utilization of plugins such as Configuration Manager for Jira (bug introduced on version 6.7.0 of the plugin - the fix was added on 6.7.3), could cause this problem in the database.

Note: As per the feedback from Botron engineers, the plugin is scheduled to release the lock after 24 hours, which may cause the issue to seem like it was resolved by itself.

Solution

Resolution

⚠️ Back up the Jira database before proceeding.
Shut down Jira.
Run the SQL command below:
1UPDATE "AO_60DB71_LEXORANK" SET "LOCK_HASH" = NULL, "LOCK_TIME" = NULL;
Start Jira again.
Run a Full Re-index operation if the re-indexing errors in the beginning of the page were observed.
Run LexoRank re-balance for all fields.

You can also check the logs in the atlassian-jira.log file. To do this, enable the package com.atlassian.greenhopper.manager.lexorank.

Here's an example:

2023-09-22 13:57:20,761 lexorank-executor-thread-0 DEBUG      [greenhopper.manager.lexorank.LexoRankDaoImpl] Acquiring Lexorank lock: 738b71cd-44d0-40fa-91de-227fedb1d10b
 2023-09-22 13:57:20,762 lexorank-executor-thread-0 DEBUG      [greenhopper.manager.lexorank.LexoRankDaoImpl] Acquired Lexorank lock: 738b71cd-44d0-40fa-91de-227fedb1d10b
 2023-09-22 13:57:20,762 lexorank-executor-thread-0 DEBUG      [greenhopper.manager.lexorank.LexoRankDaoImpl]  LexoRank Query : SELECT FIELD_ID,ID,ISSUE_ID,LOCK_HASH,LOCK_TIME,RANK,TYPE FROM PUBLIC.AO_60DB71_LEXORANK WHERE FIELD_ID = ? ORDER BY RANK DESC LIMIT 2; params[10000]
 2023-09-22 13:57:20,762 lexorank-executor-thread-0 DEBUG      [greenhopper.manager.lexorank.LexoRankDaoImpl] Releasing Lexorank lock: 738b71cd-44d0-40fa-91de-227fedb1d10b
 2023-09-22 13:57:20,763 lexorank-executor-thread-0 DEBUG      [greenhopper.manager.lexorank.LexoRankDaoImpl] Released lexorank lock: 738b71cd-44d0-40fa-91de-227fedb1d10b
 2023-09-22 13:57:20,763 lexorank-executor-thread-0 INFO      [service.lexorank.balance.LexoRankBalancerProgressLogger] Balancing rank field with id[10000] - 1 out of 2 rows (50%) complete.
 2023-09-22 13:57:20,764 lexorank-executor-thread-0 DEBUG      [greenhopper.manager.lexorank.LexoRankDaoImpl]  LexoRank Query : SELECT FIELD_ID,ID,ISSUE_ID,LOCK_HASH,LOCK_TIME,RANK,TYPE FROM PUBLIC.AO_60DB71_LEXORANK WHERE FIELD_ID = ? AND BUCKET = ? ORDER BY RANK DESC LIMIT 1; params[10000, 0]
 2023-09-22 13:57:20,764 lexorank-executor-thread-0 DEBUG      [greenhopper.manager.lexorank.LexoRankDaoImpl]  LexoRank Query : SELECT FIELD_ID,ID,ISSUE_ID,LOCK_HASH,LOCK_TIME,RANK,TYPE FROM PUBLIC.AO_60DB71_LEXORANK WHERE FIELD_ID = ? AND BUCKET = ? ORDER BY RANK ASC LIMIT 1; params[10000, 1]

Here are the available logs:

log.debug("Acquired Lexorank lock: " + lock.hash + "; Failed to lock all entities. Expected %d but locked only %d", lock.getCount(), numberOfUpdates);
log.debug("Acquired Lexorank lock: " + lock.hash);
log.debug("Releasing Lexorank lock: " + lock.hash);
log.debug("Released lexorank lock: " + lock.hash);
log.debug(" LexoRank Query : %s", selectStatement.toSql());
log.debug("Acquiring Lexorank lock: " + lock.hash);

Updated on April 8, 2025

Was this helpful?

It wasn't accurateIt wasn't clearIt wasn't relevant

Atlassian Support