Transition fails if code runs from a new thread

Hi Developer Community,

I am using a manually created thread pool to perform actions such as transition of issues. The written transition code is working when called directly via rest. But fails when calling via inside thread pool thread. On Jira, it shows the transition is complete but the transition buttons still shows as the issue was in previous state. Any help would be appreciated. Jira version is 8.5.4.

1 Like

Short answer: don’t create your own threads.
Long answer: a lot of the atlassian managers,factories, services etc use threadlocals - especially for caching. Creating your own threads really messes with that stuff.

If you need to do stuff in the background - use atlassian-scheduler


So I have a lot of rest calls coming into Jira and also scheduled jobs which performs different actions concurrently. If I don’t use thread pool then I am worried about Jira HTTP request thread getting occupied and slowing down Jira responsiveness. This was the reason I implemented thread pool in first place. Do you have a better way to perform concurrent actions without slowing down Jira?

In those cares - store the jobs in the db through Activeobjects and then process them in batches using atlassian-scheduler. I would have each trigger to be on a timer so that you don’t have multiple jobs on top of each other.


One last question, as i am a newbie in data center related plugin development. I eventually have to upgrade the code from server to be compatible with data center. I believe Atlassian provides a guide line to spawn separate threads(or JVM not sure about this) to run long running task in DC. How do you do that if you are reliant on scheduler to run long running task? As new threads will still not work with Jira back end API.

1 Like

Hi, you should have a look at this page:

Everything what daniel said is true. For DataCenter we have used ClusterLocks in the background tasks to make sure a task only runs e.g. once per cluster. And we used Caches - not too many, but for those queries that are often triggered and potentially stay the same. We have e.g. some globalSettings that are always the same for all users, that is something we cached cluster wide. :slight_smile: