Mike Drob commented on SOLR-9524:

Chatted with [~mbraun688] about this a bit...

I think {{computeIfAbsent}} is close to what we want, but it doesn't let us 
easily preserve the current behaviour to throw {{IOException}} - we'd have to 
wrap it as an RTE. I'm also a little sceptical of the claim that multiple 
threads would be attempting to calculate the same fingerprint, since this is 
only called when we open a new searcher.

I'll agree that it may be expensive, but I don't what code paths we are trying 
to protect against. And I think we'd get much better gains by doing the 
optimizations at the lower level... There's a note in IndexFingerprint that 
{{// TODO: this could be parallelized, or even cached per-segment if 
performance becomes an issue}}, which I think is where we should look instead 
of trying to ensure that a fingerprint is only calculated once.

If we _do_ need to ensure that each fingerprint is only calculated once for 
performance issues, then we should switch to a more granular locking mechanism. 
Possibly something like striped locking, or a parallel Map<Long, Lock>. This is 
a lot more complexity.

> SolrIndexSearcher.getIndexFingerprint uses dubious sunchronization
> ------------------------------------------------------------------
>                 Key: SOLR-9524
>                 URL: https://issues.apache.org/jira/browse/SOLR-9524
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>    Affects Versions: 6.3
>            Reporter: Mike Drob
> In SOLR-9310 we added more code that does some fingerprint caching in 
> SolrIndexSearcher. However, the synchronization looks like it could be made 
> more efficient and may have issues with correctness.
> https://github.com/apache/lucene-solr/blob/branch_6x/solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java#L2371-L2385
> Some of the issues:
> * Double checked locking needs use of volatile variables to ensure proper 
> memory semantics.
> * sync on a ConcurrentHashMap is usually a code smell

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to