You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mark Miller (JIRA)" <ji...@apache.org> on 2013/05/30 18:06:20 UTC

[jira] [Commented] (SOLR-4816) Add document routing to CloudSolrServer

    [ https://issues.apache.org/jira/browse/SOLR-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13670439#comment-13670439 ] 

Mark Miller commented on SOLR-4816:
-----------------------------------

I'll do a review shortly.

bq. It does this all by default, no switches needed.

bq. exception that condenses the info from each shard into a single response

How can that be backward compat if people are parsing the response? I'm not convinced you can do all this by default and be back compat, but I'll look at the latest patch.

And batch will again have the slight change in runtime behavior.

I still think these extras will need to be off by default until 5.
                
> Add document routing to CloudSolrServer
> ---------------------------------------
>
>                 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
>            Assignee: Mark Miller
>            Priority: Minor
>             Fix For: 5.0, 4.4
>
>         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.patch, SOLR-4816.patch, SOLR-4816-sriesenberg.patch
>
>
> This issue adds the following enhancements to CloudSolrServer's update logic:
> 1) Document routing: Updates are routed directly to the correct shard leader eliminating document routing at the server.
> 2) Parallel update execution: Updates for each shard are executed in a separate thread so parallel indexing can occur across the cluster.
> 3) Javabin transport: Update requests are sent via javabin transport.
> These enhancements should allow for near linear scalability on indexing throughput.
> Usage:
> CloudSolrServer cloudClient = new CloudSolrServer(zkAddress);
> SolrInputDocument doc1 = new SolrInputDocument();
> doc1.addField(id, "0");
> doc1.addField("a_t", "hello1");
> SolrInputDocument doc2 = new SolrInputDocument();
> doc2.addField(id, "2");
> doc2.addField("a_t", "hello2");
> UpdateRequest request = new UpdateRequest();
> request.add(doc1);
> request.add(doc2);
> request.setAction(AbstractUpdateRequest.ACTION.OPTIMIZE, false, false);
> NamedList response = cloudClient.request(request); // Returns a backwards compatible condensed response.
> //To get more detailed response down cast to RouteResponse:
> CloudSolrServer.RouteResponse rr = (CloudSolrServer.RouteResponse)response;
> NamedList responses = rr.getRouteResponse(); 

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