Issue Summary

CHANGE_HISTORY entityVersionCache is fully cleared on each issue delete, causing repeated expensive Lucene BKD lookups and severe performance degradation on memory‑constrained, large Jira Data Center clusters.

Steps to Reproduce

1. Set up a Jira Data Center cluster with:
   • Large heap (e.g., 50 GB) and limited remaining system RAM (so that OS page cache is tight).
2. Warm up the CHANGE_HISTORY entityVersionCache by performing normal issue operations (create/update) and observe:
   • Reasonable cache hit rates.
   • Low replaceDocumentsWithVersionMillis (few ms).
3. Start deleting issues at a moderate rate from multiple nodes/users during peak activity.

Expected Results

• Deleting an issue should invalidate/evict only the cache entries relevant to that issue (or at least minimally necessary entries), not the whole cache.
• Avoid causing cluster-wide cache wipes for unrelated entities.

Actual Results

• WriterWrapper.deleteDocuments() clears the entire entityVersionCache whenever an issue is deleted.
• In a cluster, this cache clear is replicated to all nodes.
• Under steady or bursty deletion patterns, caches on some nodes rarely warm up, forcing frequent disk‑backed BKD tree lookups for CHANGE_HISTORY updates, resulting in high latency and node health issues.

Workaround

These are operational mitigations, not fixes for the code‑level bug:

• Reduce JVM heap to free OS page cache (Primary Mitigation)
• Operational guidance around issue deletions (Secondary Mitigation)
  • Advise customer to avoid concentrated bursts of deletions during peak hours.
  • Encourage bulk cleanup (e.g., backlog grooming, mass deletions) to be performed outside peak business hours