Problem

When a user opens a saved coverage view or creates a new one, there is a prompt:

Cause

Coverage rendering and export has been reported by a number of R4J customers of causing their Jira instance to become slow, unstable, or ultimately crash. This occurs because of the large heap consumption needed to generate coverage, esp. one with large data.

Due to this, from R4J version 4.4.4+, the coverage has been restricted to require more than 30% free needed memory to avoid any unwanted effect to a Jira instance.

Solution

Upgrade to R4J 4.7.1 or higher.

From R4J 4.7.1, Administrators can configure the Minimum free needed memory to process coverage view. See Configuration page for full explanation.

This value is variable between Jira instances due to limiting factors, such as, environment configurations, other plugins installed, etc. Analysis and trials need to be done by the Jira Administrator to determine the most suitable value for this configuration.

Workaround(s)

As a Non-administrator User, you may try the following solutions:

1. Clear browser cache and perform hard reload / refresh in your browser when the memory limit message shows.

   • Open the Chrome Dev Tools by pressing F12.

   • Once the chrome dev tools are open, just right click on the refresh button and a menu will drop down.

   • This menu gives you the option of doing a hard refresh, or even clearing the cache and do a hard refresh automatically

2. Closing other browser tabs running Jira, aside from coverage view. Also, try to limit the number of issue(s) / coverage level(s).

3. Wait for a few minutes. Several refreshes of the page can lead to a successful run of the coverage view.

As a Jira Administrator, you may try the following solutions to minimize the effect to your users:

1. Increase Java Heap Size Limit

   • Jira Reference: Increasing Jira application memory

2. Force Garbage Collection

   • In your Jira instance, go to Administration > System > System info > Java VM Memory Statistics

   • Click "Force garbage collection" under Java VM Memory statistics. This will only cleanup unused memory in JVM and no data will be lost.