[
https://issues.apache.org/jira/browse/SOLR-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764484#comment-13764484
]
Mark Miller commented on SOLR-5232:
-----------------------------------
All SolrJ clients and non SolrJ clients should fall under 'best practice'
depending on your use case and desires. Using the new routing in
CloudSolrServer is a possible workaround for issues that should be addressed,
not worked around. Also, routing removes forwarding to leaders - you still send
documents to replicas - that is still reliant on the buffer. CloudSolrServer
can run also be used in a manner that does not route as an aside.
bq. making changing the batch size question less relevant.
As the comments on the batch size issue indicate, changing the size is not an
option we are willing to go with.
As far as speed comparisons, someone would have to do some benchmarks to know
how the new strategy holds up - it's just clearly where we have always needed
to get to eventually.
There is no similar buffer size to consider here.
> SolrCloud should distribute updates via streaming rather than buffering.
> ------------------------------------------------------------------------
>
> Key: SOLR-5232
> URL: https://issues.apache.org/jira/browse/SOLR-5232
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Mark Miller
> Assignee: Mark Miller
> Fix For: 4.5, 5.0
>
> Attachments: SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch
>
>
> The current approach was never the best for SolrCloud - it was designed for a
> pre SolrCloud Solr - it also uses too many connections and threads - nailing
> that down is likely wasted effort when we should really move away from
> explicitly buffering docs and sending small batches per thread as we have
> been doing.
--
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]
