[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=16649408#comment-16649408 ] Mark Miller commented on SOLR-6312: --- +1 > CloudSolrServer doesn't honor updatesToLeaders constructor argument > --- > > Key: SOLR-6312 > URL: https://issues.apache.org/jira/browse/SOLR-6312 > Project: Solr > Issue Type: Bug > Components: clients - java, SolrJ >Affects Versions: 4.9, 7.5 >Reporter: Steve Davids >Priority: Major > Fix For: 4.10 > > Attachments: SOLR-6312.patch > > > 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 (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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=16647987#comment-16647987
]
Jason Gerlowski commented on SOLR-6312:
---
Wanted to re-bring this to people's attention if I could. It's gotta be really
confusing for our users that {{CloudSolrClient.Builder}} has 4 different
methods all involving how updates are sent to shards. None of them are well
documented, and 2 of them have had no effect for the last 4 years or so.
I came to this because I wanted to add Javadocs to these methods and was
surprised to find that they don't do anything. I felt like it would be a
little silly to have javadocs saying: "These methods don't have any effect.
They used to have an effect, but now we're just keeping them around as a
vestigial organ", so I thought I would maybe poke this thread again.
I don't have a strong preference what we do with these methods. I buy Steve's
and Hoss' point that having this setting would be beneficial for those doing
work in their update-request-chains that they want to spread around different
nodes. But it's unclear when someone will have the time/priority to make this
happen and in the meantime I'd hate to see us let the "perfect" (this cool new
functionality) get in the way of the "good" (less confusing interface).
Would anyone care if I added a deprecation warning to these methods?
Deprecation doesn't need to be final...if someone gets around to implementing
this functionality, we can always remove the deprecation. We should do
_something_ to steer users away from using the methods in their current state.
I'd vote for temporary-deprecation since that catches the eye a little more
than a Javadoc that you don't see unless think to go look it up. But if others
still object I'll just add a little javadoc warning.
> CloudSolrServer doesn't honor updatesToLeaders constructor argument
> ---
>
> Key: SOLR-6312
> URL: https://issues.apache.org/jira/browse/SOLR-6312
> Project: Solr
> Issue Type: Bug
> Components: clients - java, SolrJ
>Affects Versions: 4.9, 7.5
>Reporter: Steve Davids
>Priority: Major
> Fix For: 4.10
>
> Attachments: SOLR-6312.patch
>
>
> 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
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[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=16208362#comment-16208362 ] Jeff Wartes commented on SOLR-6312: --- As of 7.0.1, three years later, yes, I think it is still an open issue. CloudSolrServer.Builder has two functions that have no effect: sendUpdatesOnlyToShardLeaders and sendUpdatesToAllReplicasInShard. They are not marked depreciated, and the javadoc implies functionality. > 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 > > Attachments: SOLR-6312.patch > > > 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.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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=15755215#comment-15755215 ] Anshum Gupta commented on SOLR-6312: Is this still an open issue? Considering only the builder pattern is now a non-deprecated way to construct the client, do we still end up with this when we use _sendDirectUpdatesToAnyShardReplica()_ ? > 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 > > Attachments: SOLR-6312.patch > > > 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.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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=15352997#comment-15352997 ] Christine Poerschke commented on SOLR-6312: --- Refreshed patch file for SOLR-9090 (which is related to this ticket but also slightly different), with a view towards committing the change towards the end of this or beginning of next week. Questions, comments, reviews etc. welcome as usual. Thank you. > 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 > > Attachments: SOLR-6312.patch > > > 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.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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=14942743#comment-14942743 ] Mark Miller commented on SOLR-6312: --- Interesting - I think I'm seeing lots of fails of our partition tests fail if I make this change. Just to have to verify I'm not seeing that without the change. > 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 > > Attachments: SOLR-6312.patch > > > 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.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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=14942752#comment-14942752 ] Mark Miller commented on SOLR-6312: --- Yeah, seems to be the case. I know it's more strain on the cluster to not send directly to leaders, but I wonder if some setting somewhere needs to be relaxed so that we don't keep hitting this 'no healthy nodes found' fail. > 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 > > Attachments: SOLR-6312.patch > > > 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.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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=14942841#comment-14942841 ] Mark Miller commented on SOLR-6312: --- Actually I think the tests just need a little hardening. > 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 > > Attachments: SOLR-6312.patch > > > 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.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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=14942843#comment-14942843 ] Mark Miller commented on SOLR-6312: --- Interesting - just got a replica out of sync issue with the shard split test with sendUpdatesToLeaders=false. Don't think I've seen that in some time without. I'll keep an eye on it. > 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 > > Attachments: SOLR-6312.patch > > > 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.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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-tabpanelfocusedCommentId=14113827#comment-14113827 ] Mark Miller commented on SOLR-6312: --- +1. 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 Attachments: SOLR-6312.patch 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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-tabpanelfocusedCommentId=14093983#comment-14093983 ] Steve Davids commented on SOLR-6312: Yes, I understand that all updates will always go to the leader, the CPU intensive task in this entire process is running extraction logic using XPaths in the update processor chain before any requests are distributed to the leader/replicas. When the request is distributed to the leader, the leader doesn't need to start the update processor from scratch, instead it continues where the other machine left off in the processing pipeline at the DistributedUpdateProcessor. So if I am able to load balance requests to all replicas the CPU intensive tasks (early update processors) will be shared by multiple machines not just the leader and should result in increased throughput. 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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-tabpanelfocusedCommentId=14094170#comment-14094170 ] Erick Erickson commented on SOLR-6312: -- Hmmm, interesting problem here. This is why, for scaling purposes, I vastly prefer doing any such heavy lifting on the clients so I can scale up by racking N clients together rather than have a Solr node be a bottleneck due to the parsing. Is that a possibility? So I suspect we can close this JIRA? You're correct that updatesToLeaders is not respected, but it's also not going to be. Or perhaps change the title to depecrate CloudSolrServer updatesToLeaders constructor argument. 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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-tabpanelfocusedCommentId=14094182#comment-14094182 ] Hoss Man commented on SOLR-6312: bq. So I suspect we can close this JIRA? You're correct that updatesToLeaders is not respected, but it's also not going to be. Steve's use case (and similar usecases like it, ie: using the ExtractingRequestHandler on large binary data files) actually strikes me as a really good reason to make upatesToLeaders==false meaningful again: randomize updates to all up replicas in the collection regardless of leader status. (the default is upatesToLeaders=true, no reason that would change, no reason it would impact anyone except people like steve trying to distribute the load of early logic to non-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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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-tabpanelfocusedCommentId=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=revisionrevision=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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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-tabpanelfocusedCommentId=14093503#comment-14093503 ] Steve Rowe commented on SOLR-6312: -- bq. I think the bug here is mark the updatesToLeaders option deprecated, and remove it in trunk. The updatesToLeader option has been disconnected from the way CloudSolrServer operates for 11 months now, 5 feature releases ago - what's the point of deprecating non-existent functionality? (Jessica Cheng noted this problem a ways back [on SOLR-4816|https://issues.apache.org/jira/browse/SOLR-4816?focusedCommentId=13792911page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13792911].) I vote for outright removal - that should have happened when SOLR-4816 was committed in [r1521713|http://svn.apache.org/r1521713]. 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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-tabpanelfocusedCommentId=14093508#comment-14093508 ] Hoss Man commented on SOLR-6312: bq. what's the point of deprecating non-existent functionality? correct compilation w/o modification of existing client code on upgrade. 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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-tabpanelfocusedCommentId=14093524#comment-14093524 ] Anshum Gupta commented on SOLR-6312: bq. correct compilation w/o modification of existing client code on upgrade +1 for that. The public methods/constructor shouldn't be broken (even if they were superficial) in a single release. 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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-tabpanelfocusedCommentId=14093533#comment-14093533 ] Steve Davids commented on SOLR-6312: bq. 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. [~hossman] You are correct, that is what I am seeing as well. Though I have a re-indexing use-case where I would actually like to distribute update requests to more than just the leader. I am currently performing XPath extraction logic in the update chain before distributed the requests to replicas, the problem I am running into is that the leader's CPU is completely pegged running the XPaths while the replicas are almost idle (~20%). I looked to this feature to allow more throughput by load balancing the extraction logic to the replicas and just forwarding the complete/hydrated document to the leader. I know this is a somewhat fringe case but still think it can be useful. 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[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-tabpanelfocusedCommentId=14093752#comment-14093752 ] Ramkumar Aiyengar commented on SOLR-6312: - It's unlikely you will see a difference by sending to all replicas instead of targeting the leaders, as the replicas will internally forward your requests to the leader anyway, that's the way SolrCloud is designed -- updates always go to the leader. All CSS is trying to do is save you the extra hop (and some cpu/latency savings in the process). 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
