viliam-durina opened a new pull request, #15830: URL: https://github.com/apache/lucene/pull/15830
`Condition.signal/await` was used to wake up the background thread to reload data. Since the background thread isn't owning the condition's lock at all times, notification can be lost. Specifically, if a new waiter arrives while doing `maybeRefreshBlocking()` and before it obtains the lock again, the thread will go to sleep, instead of refreshing again. Similarly, the thread won't terminate if `close()` is called during this window. The issue is pronounced if minTime is 0 and maxTime is high. Owning the lock all the time is not a solution, because it would unnecessarily block all waiters, even if they are not interested in the generation being loaded. This PR replaces this notification with a semaphore. The semaphore collects permits, and the background thread tries to acquire a permit with a timeout as a way of sleeping. Releasing a permit serves as the signal. This way no notification is lost. There's another wait-notify construct in this class, but that one is correct. The waiter owns the lock all the time, and the write to `searchingGen` is done while holding the same monitor. Other changes included in this PR: - simplify the background thread loop (the `run()` method), now it's simple steps: loop until finished, in each iteration determine sleep time, if >0, sleep, else refresh. - move `refreshStartGen` to the listener class, it's used only there - clarify javadocs: This class is the `Thread` itself, not a utility. The user has to run it. And more... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
