[
https://issues.apache.org/jira/browse/SOLR-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller resolved SOLR-4046.
-------------------------------
Resolution: Duplicate
> An instance of CloudSolrServer is not able to handle consecutive request on
> different collections o.a.
> ------------------------------------------------------------------------------------------------------
>
> Key: SOLR-4046
> URL: https://issues.apache.org/jira/browse/SOLR-4046
> Project: Solr
> Issue Type: Bug
> Components: clients - java, SolrCloud
> Affects Versions: 4.0
> Environment: Solr 4.0.0. Actually revision 1394844 on branch
> lucene_solr_4_0 but I believe that is the same
> Reporter: Per Steffensen
> Priority: Critical
> Attachments: SOLR-4046.patch
>
>
> CloudSolrServer saves urlList, leaderUrlList and replicasList on instance
> level, and only recalculates those lists in case of clusterState changes. The
> values calculated for the lists will be different for different
> target-collections. Therefore they also ought to recalculated for a request
> R, if the target-collection for R is different from the target-collection for
> the request handled just before R by the same CloudSolrServer instance.
> Another problem with the implementation in CloudSolrServer is with the
> lastClusterStateHashCode. lastClusterStateHashCode is updated when the first
> request after a clusterState-change is handled. Before the
> lastClusterStateHashCode is updated one of the following two sets of lists
> are updated:
> * In case sendToLeader==true for the request: leaderUrlList and replicasList
> are updated, but not urlList
> * In case sendToLeader==false for the request: urlList is updated, but not
> leaderUrlList and replicasList
> But the lastClusterStateHashCode is always updated. So even though there was
> just one collection in the world there is a problem: If the first request
> after a clusterState-change is a sendToLeader==true-request urlList will
> (potentially) be wrong (and will not be recalculated) for the next
> sendToLeader==false-request to the same CloudSolrServer instance. If the
> first request after a clusterState-change is a sendToLeader==false-request
> leaderUrlList and replicasList will (potentially) be wrong (and will not be
> recalculated) for the next sendToLeader==true-request to the same
> CloudSolrServer instance.
> Besides that it is a very bad idea to have instance- and
> local-method-variables with the same name. CloudSolrServer has an instance
> variable called urlList and method CloudSolrServer.request has a
> local-method-variable called urlList and the method also operates on instance
> variable urlList. This makes the code hard to read.
> Havnt made a test in Apache Solr regi to reproduce the main error (the one
> mentioned at the top above) but I guess you can easily do it yourself:
> Make a setup with two collections "collection1" and "collection2" - no
> default collection. Add some documents to "collection2" (without any
> autocommit). Then do cloudSolrServer.commit("collection1") and afterwards
> cloudSolrServer.commit("collection2") (use same instance of CloudSolrServer).
> Then try to search collection2 for the documents you inserted into it. They
> ought to be found, but are not, because the
> cloudSolrServer.commit("collection2") will not do a commit of collection2 -
> it will actually do a commit of collection1.
> Well, actually you cant do cloudSolrServer.commit(<collection-name>) (the
> method doesnt exist), but that ought to be corrected too. But you can do the
> following instead:
> {code}
> UpdateRequest req = new UpdateRequest();
> req.setAction(UpdateRequest.ACTION.COMMIT, true, true);
> req.setParam(CoreAdminParams.COLLECTION, <collection-name>);
> req.process(cloudSolrServer);
> {code}
> In general I think you should add misc tests to your test-suite - tests that
> run Solr-clusters with more than one collection and makes clever tests on
> that.
--
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
