Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-68477

Workflow scheme actions leave left-over rows in 'clusterlockstatus' table.

XMLWordPrintable

      Summary
      When deleting something in a workflow scheme on Jira Data Center, the entry in the 'clusterlockstatus' table remains left behind. The 'locked_by_node' for that row will be empty, but they pile up in large numbers.

      Environment
      Jira Data Center 7.6.1/7.8.4 with two nodes
      Postgres 9.3


      Steps to Reproduce

      Scenario A, delete a workflow scheme
      1. Delete a workflow scheme.
      2. Once deleted, the 'clusterlockstatus' table will have a new entry like the example below (trailing number is corresponding to 'id' in 'workflowscheme' table.)

        id   |                                              lock_name                                               | locked_by_node |  update_time  
-------+------------------------------------------------------------------------------------------------------+----------------+---------------
 10505 | com.atlassian.jira.workflow.DefaultWorkflowSchemeManager$WorkflowAction.DELETE_SCHEME_10102          |                | 1542810654292

      3. Repeat step 1 and another entry will be there (and so on).

        id   |                                              lock_name                                               | locked_by_node |  update_time  
-------+------------------------------------------------------------------------------------------------------+----------------+---------------
 10505 | com.atlassian.jira.workflow.DefaultWorkflowSchemeManager$WorkflowAction.DELETE_SCHEME_10102          |                | 1542810654292
 10506 | com.atlassian.jira.workflow.DefaultWorkflowSchemeManager$WorkflowAction.DELETE_SCHEME_10101          |                | 1542810700419

      Scenario B, changing the associated issue types
      Edit a workflow scheme and add or remove an issue type.

      Adding issue type to workflow scheme, 2 new rows added.

       10517 | com.atlassian.jira.workflow.DefaultWorkflowSchemeManager$WorkflowAction.DELETE_ENTITY_10108                |                | 1542812132748
 10518 | com.atlassian.jira.workflow.DefaultWorkflowSchemeManager$WorkflowAction.DELETE_ENTITY_10109                |                | 1542812132763
(67 rows)

      Removing issue type from workflow scheme, 3 new rows added.

       10519 | com.atlassian.jira.workflow.DefaultWorkflowSchemeManager$WorkflowAction.DELETE_ENTITY_10110                |                | 1542812218880
 10520 | com.atlassian.jira.workflow.DefaultWorkflowSchemeManager$WorkflowAction.DELETE_ENTITY_10111                |                | 1542812218891
 10521 | com.atlassian.jira.workflow.DefaultWorkflowSchemeManager$WorkflowAction.DELETE_ENTITY_10112                |                | 1542812218904
(70 rows)

      (trailing number corresponding to 'id' in 'workflowschemeentity')

       

      Expected Results
      Once the operation is done, the entry in the 'clusterlockstatus' should be removed.


      Actual Results
      'lock_name' entries like "com.atlassian.jira.workflow.DefaultWorkflowSchemeManager$WorkflowAction.DELETE_ENTITY_10105" pile up in the 'clusterlockstatus' table.
      One customer had over 8000 of them.

      Note
      Caused by JRASERVER-69114

      Workaround
      
If necessary, delete the unnecessary 'lock_name' entries manually.

              Unassigned Unassigned
              mkarlsson Magnus Karlsson
              Votes:
              11 Vote for this issue
              Watchers:
              11 Start watching this issue

                Created:
                Updated: