Is the "lock wait timeout exceeded" on OS_CURRENTSTEP error condition due to database misconfiguration or an internal Jira error?

[Chris Cain]

We are regularly but not reliably encountering this problem when a user attempts to initiate a workflow transition. The stack trace in the log is quite lengthy but starts out like so:

2012-02-02 11:36:41,473 http-8080-10 ERROR BarnetJA 695x21691x8 ve2g0a 165.127.154.34 /secure/CommentAssignIssue.jspa [atlassian.jira.workflow.OSWorkflowManager] Caught exception while attempting to perform action 41 from workflow 10251 on issue 'GEN-24'

com.opensymphony.workflow.StoreException: Error marking step #11108 finished: root cause: while updating: [GenericEntity:OSCurrentStep][caller,BarnetJA][id,11108][startDate,2012-02-02 11:23:07.0][status,Not Done][owner,][finishDate,2012-02-02 11:35:50.363][actionId,41][stepId,4][dueDate,null][entryId,10251] (SQL Exception while executing the following:UPDATE OS_CURRENTSTEP SET ENTRY_ID=?, STEP_ID=?, ACTION_ID=?, OWNER=?, START_DATE=?, DUE_DATE=?, FINISH_DATE=?, STATUS=?, CALLER=? WHERE ID=? (Lock wait timeout exceeded; try restarting transaction))

at com.opensymphony.workflow.spi.ofbiz.OfbizWorkflowStore.markFinished(OfbizWorkflowStore.java:241)

at com.opensymphony.workflow.AbstractWorkflow.createNewCurrentStep(AbstractWorkflow.java:1473)

at com.opensymphony.workflow.AbstractWorkflow.transitionWorkflow(AbstractWorkflow.java:1256)

at com.opensymphony.workflow.AbstractWorkflow.doAction(AbstractWorkflow.java:567)

at com.atlassian.jira.workflow.OSWorkflowManager.doWorkflowActionInsideTxn(OSWorkflowManager.java:905)

at com.atlassian.jira.workflow.OSWorkflowManager.doWorkflowAction(OSWorkflowManager.java:865)

at com.atlassian.jira.bc.issue.DefaultIssueService.transition(DefaultIssueService.java:505)

at com.atlassian.jira.bc.issue.DefaultIssueService.transition(DefaultIssueService.java:513)

at com.atlassian.jira.web.action.issue.CommentAssignIssue.doExecute(CommentAssignIssue.java:197)

at webwork.action.ActionSupport.execute(ActionSupport.java:165)

at com.atlassian.jira.action.JiraActionSupport.execute(JiraActionSupport.java:76)

This seems to me to be a Jira internal problem - why would that row be locked for so long? However, I don't see any evidence that other Jira installations have encountered this problem, which suggests that it could be specific to our database setup (mysql 5.1.44, Jira 4.4.4).

I'd appreciate any ideas about how to fix this.

[tier-0 grump]

Chris, I think this is related to https://jira.atlassian.com/browse/JRA-25914 as this is where we've made the transaction changes to support this, it may be best to raise this as a support issue so we can get some more information and try to replicate.

[Chris Cain]

Thanks for the suggestion. To me it sounds like a different issue than the one you cite, but I've opened a support ticket at https://support.atlassian.com/browse/JSP-115215 and we'll see what we discover.

[Alex Elman]

I'd like to bump this issue. We encounter this issue exactly once per day and always requires a restart.

Attached is a graph of our MySQL connection pool when this happens.

jiradb_connection_pool_2016-12-15.png