[ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org