Details
-
Suggestion
-
Resolution: Unresolved
-
None
-
0
-
Description
Issue Summary
When the indexing thread fails to obtain the read lock for the index, it doesn't log this event. Only when the read lock timeout happens, which by default is 30 seconds, an error is logged with the timeout:
2020-11-10 15:28:18,570-0300 RMI TCP Connection(64290)-10.22.22.22 ERROR [c.a.j.issue.index.DefaultIndexManager] Wait attempt timed out - waited 90000 milliseconds com.atlassian.jira.issue.index.IndexException: Wait attempt timed out - waited 90000 milliseconds
We should log when the thread fails to get the read lock including the thread which holds the lock. This makes the troubleshooting easier.
Steps to Reproduce
On environments experiencing I/O throughput problems, it has been observed this problem when large replication/reindex operations are being performed. Such as in SLA updates for JSD projects, which triggers a replication operation. The index file is locked but without analyzing the audit logs it is difficult to understand what is holding the lock for the index.
Expected Results
When the index is locked and threads are unable to obtain the read lock, the thread holding the lock should be logged and an error about the index read lock failure – not only when the timeout happens – at INFO level (without requiring any debugging to be enabled). As per JRASERVER-63188, it has been implemented logging which prints which tread is holding the write lock only when another thread wants the exclusive lock.
Actual Results
The thread holding the read lock is not logged.
Attachments
Issue Links
- is related to
-
JRASERVER-71814 Jira should log the event when thread fails to obtain the write lock at INFO level
- Gathering Interest