[
https://issues.apache.org/jira/browse/SOLR-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669238#comment-13669238
]
Mark Miller commented on SOLR-4816:
-----------------------------------
bq. Why not just add a a high performance update method to CloudSolrServer.
Heh - and now we are back to that. I'm less hesitant about it now that we have
come full circle.
I think if the std path does the goodness by default - with non of the multi
threading or response changing, I would be fine with another 'high performace'
method that did extra stuff and has a new response.
I really don't like the idea of giving up on a good default for CloudSolrServer
in 4x - it's fairly easy to get done. Another method is an easy to miss hack I
think - this should work nicely within the SolrServer interface.
How hard would it to be to get a single thread and the same response on the
default path - and then add options to enable more threads (and a pretty small
runtime change) and the fine grained response? Then we could mark those as
experimental options. The default path will hash client side, and options will
enable the higher performance / better response?
> ConcurrentUpdateCloudSolrServer
> -------------------------------
>
> Key: SOLR-4816
> URL: https://issues.apache.org/jira/browse/SOLR-4816
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Affects Versions: 4.3
> Reporter: Joel Bernstein
> Priority: Minor
> Attachments: SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch,
> SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch,
> SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch,
> SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch,
> SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch,
> SOLR-4816-sriesenberg.patch
>
>
> This issue adds a new Solr Cloud client called the
> ConcurrentUpdateCloudSolrServer. This Solr Cloud client implements document
> routing in the client so that document routing overhead is eliminated on the
> Solr servers. Documents are batched up for each shard and then each batch is
> sent in it's own thread.
> With this client, Solr Cloud indexing throughput should scale linearly with
> cluster size.
> This client also has robust failover built-in because the actual requests are
> made using the LBHttpSolrServer. The list of urls used for the request to
> each shard begins with the leader and is followed by that shard's replicas.
> So the leader will be tried first and if it fails it will try the replicas.
> Sample usage:
> ConcurrentUpdateCloudServer client = new
> ConcurrentUpdateCloudSolrServer(zkHostAddress);
> UpdateRequest request = new UpdateRequest();
> SolrInputDocument doc = new SolrInputDocument();
> doc.addField("id", 2);
> doc.addField("manu","BMW");
> request.add(doc);
> NamedList response = client.request(request);
> NamedList exceptions = response.get("exceptions"); // contains any exceptions
> from the shards
> NamedList responses = response.get("responses"); // contains the responses
> from shards without exception.
>
--
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]
