How a Change to Caching Logic in Atlassian Jira 8.2.x May Impact you

by | Jan 15, 2020

Atlassian released Jira 8.2.x, a few months back which includes a fix to JRASERVER-66555 – JIRA uses excessive amount of memory during issue export. This is a really great fix on their part, and will do a lot to help clients provide a more stable and reliable experience for their users while reducing the resources required by Jira. By limiting cache size, and ejecting cached values rapidly, there is now a use case which may impact a system and cause excessive Database connections. See the ticket for a more detailed explanation of the change. However, we engaged the Atlassian dev team in a conversation in the comments and they helped us understand what the downside of this change is. The relevant comment came from Ilya Zinoviev:

However, if there is a code looking smth like the following, it can become slower.

[pastacode lang=”java” manual=”for%20(CustomField%20cf%20%3A%20customFields)%20%7B%0A%20%20%20%20for%20(Issue%20issue%20%3A%20issues)%20%7B%20%20%20%20%20%2F%2Fissues.size()%20%3E%2010%0A%20%20%20%20%20%20%20%20%20Object%20value%20%3D%20customField.getValue(issue)%3B%0A%20%20%20%20%7D%0A%7D” message=”” highlight=”” provider=”manual”/]

In such case, yes, cache is going to be flushed and twice more db calls would be needed.
The fix would be quite simple: change order of iteration:

[pastacode lang=”java” manual=”for%20(Issue%20issue%20%3A%20issues)%20%7B%20%20%20%20%20%2F%2Fissues.size()%20%3E%2010%0A%20%20%20%20for%20(CustomField%20cf%20%3A%20customFields)%20%7B%0A%20%20%20%20…” message=”” highlight=”” provider=”manual”/]

Atlassian has tested this, and it is unlikely to cause any issues in a stock system. And while I can’t speak for all third party App vendors, I have personally shared this with some of the larger ones for them to ensure that their apps are reviewed to ensure that they won’t negatively impact a client system. However, there is still one area of risk for large organization, any custom scripts that you have written. There are a number of popular apps that allow you to write your own scripts which run within Jira such as Script RunnerPower Scripts, and Scripting Suite. If you are using any of these, or any other scripting Apps, then you should audit your script library and ensure that you’re not following this code pattern.

It is also worth noting, that when you upgrade to 8.2.x+ in your test environment, that you should monitor DB connection count in your testing to ensure that everything is working as expected.

We expect to see a lot of clients upgrading to Jira 8.5 as the new Enterprise Release. This is one of the changes you should be keeping an eye out for.

If you need help reviewing your code, or anything else, please contact us!

Subscribe to receive our monthly
blog posts in your inbox

Latest Blogs
Share This