From Chris Fuller comment on this Answers thread, we have a piece of code we can make it better (point 2).

Chris FullerOct 25, 2016
From the stack trace a bit of digging, my guesses are:

1. I don't see any custom settings on this cache, so we seem to be using synchronous replication by default. There may be an opportunity to improve performance here by making cache replication asynchronous instead, but that could also cause instability if parts of the system don't respond as well to eventual consistency semantics, so it would need a lot of testing.

1. This particular cache is doing a removal (and thus a replicated event) on every read request, which is just plain dumb. You should report this to support. The nasty code is this (from CachingTaggingAvatarStore):

@Override
public Avatar getByIdTagged(final Long avatarId) {
    try {
        return taggedAvatars.get(avatarId, () -> tagAndRetrieve(avatarId)).orElse(null);
    } finally {
        avatars.remove(avatarId);
    }
}

That `remove` probably isn't necessary at all. The point is that once an avatar is "tagged" with the metadata that confirms it came from JIRA, we don't need to hold onto the untagged version of it anymore. But on a cache hit, that untagged one is already gone, so the remove on the untagged avatar is just wasteful. It could be moved inside the loading function or possibly removed altogether, depending on what the surrounding code does (I didn't dig in further than that).