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:
We should log when the thread fails to get the read lock including the thread which holds the lock. This makes the troubleshooting easier.
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.
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.
The thread holding the read lock is not logged.