[
https://issues.apache.org/jira/browse/SOLR-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13776964#comment-13776964
]
Mark Miller commented on SOLR-5263:
-----------------------------------
It's probably time to drop that more complicated cache code - especially now
that CloudSolrServer will usually not even take that path and route on it's own.
> CloudSolrServer URL cache update race
> -------------------------------------
>
> Key: SOLR-5263
> URL: https://issues.apache.org/jira/browse/SOLR-5263
> Project: Solr
> Issue Type: Bug
> Components: clients - java, SolrCloud
> Affects Versions: 4.4, 4.5, 5.0
> Reporter: Jessica Cheng
> Labels: solrcloud, solrj
>
> In CloudSolrServer.request, urlLists (and the like) is updated if
> lastClusterStateHashCode is different from the current hash code of
> clusterState. However, each time this happen, only the cache entry for the
> current collection being requested is updated. In the following condition
> this causes a race:
> query collection A so a cache entry exists
> update collection A
> query collection B, request method notices the hash code changed and update
> cache for collection B, updates lastClusterStateHashCode
> query collection A, since lastClusterStateHashCode has been updated, no
> update for cache for collection A even though it's stale
> Can fix one of two ways:
> 1. Track lastClusterStateHashCode per collection and lazily update each entry
> 2. Every time we notice lastClusterStateHashCode != clusterState.hashCode(),
> 2a. rebuild the entire cache for all collections
> 2b. clear all current cache for collections
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
