lucene-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (Jira)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-13898) Non-atomic use of SolrCache get / put
Date Tue, 12 Nov 2019 18:43:00 GMT

    [ https://issues.apache.org/jira/browse/SOLR-13898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16972688#comment-16972688
] 

Yonik Seeley commented on SOLR-13898:
-------------------------------------

Using computeIfAbsent makes total sense for something like UnInvertedField, which is huge
and expensive and you absolutely don't want to ever build a duplicate because of a race.
With something like the filter cache, the access pattern tends to be much different and using
computeIfAbsent can be optimizing for the rare case and not the common case (well, the common
case of 100% hit rate for the types of requests that hit the filter cache many times and expect
that hit rate to get good performance... and on a miss, it's quick to compute anyway). All
those cases (variants of faceting, join, etc) are all requesting filters for terms though,
so perhaps that case could be handled differently from more complex queries.

> Non-atomic use of SolrCache get / put
> -------------------------------------
>
>                 Key: SOLR-13898
>                 URL: https://issues.apache.org/jira/browse/SOLR-13898
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>    Affects Versions: 8.3
>            Reporter: Andrzej Bialecki
>            Assignee: Andrzej Bialecki
>            Priority: Major
>             Fix For: 8.4
>
>         Attachments: SOLR-13898.patch, SOLR-13898.patch
>
>
> As pointed out by [~ben.manes] in SOLR-13817 Solr code base in many key places uses
a similar pattern of non-atomic get / put calls to SolrCache-s. In multi-threaded environment
this leads to cache misses and additional unnecessary computations when competing threads
both discover a missing value, non-atomically compute it and update the cache.
> Some of these places are known performance bottlenecks where efficient caching is especially
important, such as {{SolrIndexSearcher}}, {{SolrDocumentFetcher}}, {{UninvertedField}} and
join queries .
> I propose to add {{SolrCache.computeIfAbsent(key, mappingFunction)}} that will atomically
retrieve existing values or compute and update the cache. This will require also changing
how the {{SolrCache.get(...)}} is used in many components.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org


Mime
View raw message