ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1431546094
PR is not necessary but was the underlying bug fixed? The issue was
corrupting the cache by modifying the key’s equality while inside of a
ConcurrentHashMap. The upgrade just yells if dete
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1325654602
Released caffeine 3.1.2 with this error detection
--
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
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1300803918
oh yes, I did not notice that `Collection getClauses(Occur occur)` is
package-private. This is returning a mutable collection, but since it is not
public then that is safe (maybe package-p
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1299774688
Lucerne’s BooleanQuery clauseSets is externally mutable. The getClauses
method returns a mutable collection (hashset) so the caller might add to it. I
don’t see an occurrence, but some une
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1296493503
I have
[added](https://github.com/ben-manes/caffeine/commit/9cd509c69344e304eb3ff99fe61cd8810957e6e8)
detection for the scenario when the key's equality has changed and corrupted
the mapp
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1295894185
Reviewing the Query hierarchy and I see mutations that impact equality.
Here's the list that I found, but being unfamiliar I might have missed some
cases. Hope it helps.
- LTRQuery's `s
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1295301391
I believe it was a `WrappedQuery` holding a complex BooleanQuery, but we did
not look enough. I only recall that the key equality was complex with hashmap
comparisons, and when we inspecte
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1295282499
Thanks @uschindler. I think we need to confirm this hypothesis first. Is
there an easy way to make an immutable copy for us to test with? The actual fix
might be different, but this would
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1295272732
Thanks to @DennisBerger1984's help, we met to step through the debug session
of the cache in this invalid state. Dennis captured this [jstack
output](https://github.com/apache/solr/files/9
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1292941058
If you do come by a stacktrace please let me know. I am not having luck in a
review of the code, but a fresh set of eyes is always welcome. If you can
reproduce then look for other excepti
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1290842612
Thanks @DennisBerger1984.
> We came across this bug using JDK11 and Solr 8.11.2
> If I remember correctly ... in caffeineCache 3.3.1
I see that Solr 8.11.2 is
[using](ht
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1290160892
We will need to see the stacktrace and debug details. Caffeine’s loop
retries only if the entry was a stale read and once locked is determined to
have been already removed from the map. Th
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1289828195
> Actually this loop sometimes hits the assertion recently added in JDK 17.
I'd rewrite that infinite loop to something more "CAS" like.
Unfortunately the challenge with this method
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1289464453
Can you try jdk12? Does the stacktrace look to be related to the linked
patch?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to Gi
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1289463410
> ConcurrentHashMap#put method does not terminate an endless loop.
This could be a livelock if Solr is performing recursive writes (e.g. a
write within a computation). That is not su
ben-manes commented on PR #1118:
URL: https://github.com/apache/solr/pull/1118#issuecomment-1289458504
Is this perhaps related to the JIT loop unrolling bug
(https://github.com/ben-manes/caffeine/issues/797,
[SOLR-16463](https://issues.apache.org/jira/browse/SOLR-16463))? (/cc
@uschindler)
16 matches
Mail list logo
