Custom Field Value cache can grow indefinitely

Problem Definition

EagerLoadingOfBizCustomFieldPersister caches all Custom Field values related to specific Issue from customfieldvalue table in request-scope cache.

This caching was introduced as a performance optimisation to speed up issue indexing.
Probably it also helps in ViewIssue, issue-nav's table view and sorting by custom field through a database.

However, currently this cache can grow indefinitely and this can cause high memory pressure.

Suggested Solution

Introduce some limits to the cache size, I.e. 1/10/100 issues only

Notes

In the following example, we have cached values for 62k issues. (each having ~50 cf values)

Notes on fix

Copy from focusedCommentId=1972882

Background

In Jira many custom field values are read from DB. These values are often read in a loop, one by one. To minimise the number of DB calls, when one custom field value is read, EagerLoadingOfBizCustomFieldPersister reads and caches all of the values for the given issue. This is a request-scoped cache, so as soon as one Jira page is displayed, it's binned.

Problem

In some cases the request scope lasts for long time. This is the case for example for CSV export, where all issues are exported in one go. The cache keeps on accumulating custom field values for longer than needed - as soon as an issue has been written out, it won't be accessed any more. There's no point in keeping it in memory. Yet, until this fix, we did that.

Another example (which is not really a real web request) is when a batch of issues is indexed. As soon as one issue has been indexed, we don't need to keep it in the memory. For this we had a workaround of cleaning the cache manually, which is redundant now.

Fix summary

We changed the custom field cache from unbounded to size 10 (LRU). In most cases size 1 would be enough, but in some scenarios, e.g. reading a subtask and its parent, a slightly bigger cache will be beneficial.

Fix performance

I tested CSV export of 100K issues, each having 10 custom field values. Before the fix the request cache would have ~1945MB at the end of the export, now it has ~57MB.

Running our JPT showed no performance regression. Indexing speed wasn't impacted either.