Summary

• Jira has a '/status' endpoint which is a very lightweight endpoint that can be used by load balancers, other monitoring and admins to quickly check if that node is in a state where it is ready to process new incoming requests.
• As of JRASERVER-73281 by default the processing of the /status request includes reporting index replication, which may trigger index replication, which may be slow (in case of RMI connection issues). This slows down the /status response
• The singleton ApplicationStateResolverImpl handles /status request, where the memorization of the index check is synchronized. Thus no parallel /status requests could be processed waiting to complete.
• The index status checking is cut short by checking the system property above in the properties cache. The latter is affected by the cache replication Thus the issues with the RMI connections for cache replication slow down additionally the
  /status responses.
• The "com.atlassian.jira.status.index.check.expiration.seconds" system property controls the timeout of the index checking. It is retrieved as a system property (by-passing the properties cache).
• The com.atlassian.jira.status.index.check system property cannot change in runtime, same as "com.atlassian.jira.status.index.check.expiration.seconds", thus there is no need to look it up through the properties cache.

Suggestions

• From the checkIndexAvailable() method, remove the lookup of com.atlassian.jira.status.index lookup.check in the properties cache. This makes the method check exactly the index replication.
• Let the constructor of ApplicationStateResolverImpl read com.atlassian.jira.status.index.check as a system property (the same way as it already does for com.atlassian.jira.status.index.check.expiration.seconds) and if it is true, keep the existing logic (memorizing checkIndexAvailable()), otherwise just use an empty method (no memorization at all).

This way when the index checking is disabled, the caches will not be used at all and the /status request will be reliably fast.