I currently have 94 active automation rules that sometimes (depending on peak days) send "service limit" alerts wherein rule execution were "throttled". While Code Barrel has recommendation on how to increase Automation Service Limits, (https://codebarrel.atlassian.net/wiki/spaces/AUTO4J/pages/54200905/How+to+increase+Automation+service+limits+to+prevent+loop+detection+in+JIRA+Server?showComments=true&showCommentArea=true), I am considering using Adaptavist Scriptrunner's Script Listeners to replace some of our Automation Rules. "Fast-track transition an issue" is an ideal listener in lieu of more than half of our Automation Rules that update ticket Status based on user comments.
Before doing this however, I would like to be certain that I will I be saving JIRA resources with this alternative approach. Which one consumes less memory, an Event Listener or Automation Rule?
Thanks for your help.
I am 90% sure that listener will be faster. In my opinion the biggest problem about automation lite is that you need to define conditions by jql query. If your jql query begins to take long time for execution then you get into trouble. If your instance is small then everything is fine. If your instance grows then you may have problems with performance. Just do not select issues from jql queries in scriptrunner listener or you will have the same problem. Or avoid selecting from jql queries as much as possible. I do not want to tell that automation lite is bad. I several times recommended it. Just each plugin must be used wisely. Or you can try to optimize your jql conditions in automation lite.
the biggest problem about automation lite is that you need to define conditions by jql query.
In Automation for Jira you don't need definite issue conditions / triggers with JQL (although you can).
If the rules are being triggered off an action like "Comment" or "Edit" the app runs as an event listener for that particular issue, not as a JQL search.
In "Conditions" you can match by the field values directly, which also avoids the need to use JQL (although that option is also possible)
You're right though in that if you're optimising for performance, avoid using excessive JQL queries in your rules will be beneficial.
Hey there Doods,
Just a quick one on the limits. They're there to protect users from accidentally overloading their Jira instance. This is especially important since Project admins can configure rules as well. As global-admins, you can loosen these limits as you need to.
On the Event listener VS Automation rule side, our automation rules do run as event listeners, which then queues actions that is needed to run in the background. You can configure this to run synchronously if you want (this will in effect work like running an "Event Listener"). However, running all transformations in an event listener has the potentially to slow down over all Jira performance since this executes synchronously (this is why we background the updates by default). We try to be careful with the health of your core Jira instance as a top priority.
Definitely try out which one works better for your case though, and drop us a line if you need any help.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs