You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2014/08/12 01:18:11 UTC
[jira] [Commented] (SOLR-6312) CloudSolrServer doesn't honor
updatesToLeaders constructor argument
[ https://issues.apache.org/jira/browse/SOLR-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14093490#comment-14093490 ]
Hoss Man commented on SOLR-6312:
--------------------------------
Steve: can you elaborate a bit more on what exactly your code looks like, and what behavior you are seeing that you think is incorrect? (it's not clear if you are saying all requests, including queries, are only being sent to leaders when updatesToLeaders==true; or if you are saying that regardless of whether updatesToLeaders==true, updates are only going to hte leaders.
from what i can tell, updatesToLeaders is completely ignored in 4.9, and i _think_ should have been marked deprecated a while ago.
from what i remember of the history, updatesToLeaders was a feature in early versions of CloudSolrServer that, instead of picking a random server from the pool of all servers, would cause the code to pick a random server from one of the current leaders - which would increase the odds of saving a "hop" in the case where we were sending a commit or deleteByQuery, or we got lucky and picked the "right" leader for a doc add/delete.
But once CloudSolrServer became smart enough to be able to ask ZooKeeper for the DocRouter being used, we no longer needed to randomly pick a leader - we know exactly which leader to use for each update -- making that setting unneccessary...
https://svn.apache.org/viewvc?view=revision&revision=r1521713
So, if my understanding is correct, what you should be seeing is that _queries_ are randomly distributed to any 1 solr node, while updates are always targeted at the correct leader.
does that jive with what you are seeing?
----
I think the bug here is mark the updatesToLeaders option deprecated, and remove it in trunk. (either that, or: if there is still some code path where CloudSolrServer may not be able to figure out the DocRouter, then in _that_ situation i guess it might still make sense to round robin just among the known leaders?)
> CloudSolrServer doesn't honor updatesToLeaders constructor argument
> -------------------------------------------------------------------
>
> Key: SOLR-6312
> URL: https://issues.apache.org/jira/browse/SOLR-6312
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.9
> Reporter: Steve Davids
> Fix For: 4.10
>
>
> The CloudSolrServer doesn't use the updatesToLeaders property - all SolrJ requests are being sent to the shard leaders.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org