Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Adaptavist ScriptRunner for Jira Server Concurrent Operations

Claire Chen
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
March 3, 2023

Hi, with Adaptavist ScriptRunner v6 for Jira Server v9.2.0, we have encountered the issue where concurrent interactions with Scriptrunner listeners give incorrect outcome.

 

Steps to reproduce:

1. create 2 listeners, say listener1 and listener2

2. have two users one deleting listener1 and another user deleting listener2 at the exact SAME time

3. note that only 1 listener is successfully deleted, the other one remained undeleted but the response in network tab from the DELETE request gives 204 response code which indicates the operation has been fulfilled on Jira

 

The issue can also be reproduced when multiple users updating multiple listeners concurrently.

 

I'm interested to know if this is a known issue in Scriptrunner and whether there is recommended solution to resolve the issue given we have our api product trying to send concurrent requests updating/deleting listeners in Scriptrunner.

1 answer

1 accepted

Suggest an answer

Log in or Sign up to answer
1 vote
Answer accepted
Peter-Dave Sheehan
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 3, 2023

I think you should submit this to productsupport.adaptavist.com.

But I'm not surprised this would be the case since all listeners are stored in the application properties system under a single entry (json formatted):

Select
e.ID, e.ENTITY_NAME, e.ENTITY_ID, e.PROPERTY_KEY, t.propertyvalue
From
propertyentry e Inner Join
propertytext t On e.ID = t.ID
Where
e.PROPERTY_KEY = 'com.onresolve.jira.groovy.groovyrunner:groovyrunner'

 The REST api endpoint probably starts with loading the full list, applying the delete operation, to the list in memory, and then storing the resulting list.

If you call it simultaneously, both threads retrieve the same list, each of them deletes a different one then each of them saves the new list. This is where the concurrency error will happen, the first one to save will put the second one on pause until the record is available, so that the first one will save the new list and return 204 code. Then, when the record is released, the second one saves (with the previously deleted record still in its list) and returns a 204 code.

So both calls were successful, but one overwrote the other.

I think the only way for them to work around this would be to redesign their listener storage and use the AO object instead of the application properties so that each listener has its own row.

TAGS
AUG Leaders

Atlassian Community Events