gerlowskija commented on a change in pull request #1574:
URL: https://github.com/apache/lucene-solr/pull/1574#discussion_r445668363
##########
File path:
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java
##########
@@ -70,6 +73,11 @@
private static final Logger log =
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
+ /**
+ * A counter to ensure that no RID is equal, even if they fall in the same
millisecond
+ */
+ private static final AtomicLong ridCounter = new AtomicLong();
Review comment:
I don't think LongAdder is appropriate here - it doesn't have an
incrementAndGet or anything similar that would ensure threads get unique
counter values.
The "atomicity" that it offers, afaict, is that calls to `add(long)` can't
be clobbered across threads and will eventually be incorporated into the sum().
Nothing guarantees that two threads can't get the same `sum()` value at a
given time, without additional synchronization. I found this [SO
post](https://stackoverflow.com/questions/45269587/does-java-longadders-increment-sum-prevent-getting-the-same-value-twice)
helpful.
Now that I look at the synchronization generally though it reinforces my
impression that I need to benchmark this before I commit, to ensure the lock
contention isn't noticeable. It's a shame LongAdder doesn't look like a good
fit.
----------------------------------------------------------------
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.
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
