benwtrent commented on code in PR #13306:
URL: https://github.com/apache/lucene/pull/13306#discussion_r1578328936
##########
lucene/core/src/java/org/apache/lucene/search/LRUQueryCache.java:
##########
@@ -265,7 +269,6 @@ boolean requiresEviction() {
}
CacheAndCount get(Query key, IndexReader.CacheHelper cacheHelper) {
- assert lock.isHeldByCurrentThread();
assert key instanceof BoostQuery == false;
assert key instanceof ConstantScoreQuery == false;
final IndexReader.CacheKey readerKey = cacheHelper.getKey();
Review Comment:
As with anything multi-threaded, this is tricky. How we are actually doing
the LRU, is via the `uniqueQueries` which is a `LinkedHashMap` constructed by
`new LinkedHashMap<>(16, 0.75f, true);`
Which means, a `get` against this will actually do an UPDATE to the
LinkedHashMap order. If multiple readers attempt to do this at the same time,
I would think this would then become indeterminate.
From the java docs to `LinkedHashMap`
```
* <p><strong>Note that this implementation is not synchronized.</strong>
* If multiple threads access a linked hash map concurrently, and at least
* one of the threads modifies the map structurally, it <em>must</em> be
* synchronized externally. This is typically accomplished by
* synchronizing on some object that naturally encapsulates the map.
```
Since we have order dictated at access, not on insertion, we are modifying
the map structurally on read.
--
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: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
