[
https://issues.apache.org/jira/browse/SOLR-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764444#comment-13764444
]
Erick Erickson commented on SOLR-5232:
--------------------------------------
bq: batch size != queue size
I wasn't confusing the two, they just happen to be the same numbers. What I'm
after here is something on record as to whether we expect the anecdotal
evidence of faster indexing by increasing batch size to be affected by
streaming, making changing the batch size question less relevant.
I suppose with Joel's/Mark's changes to CloudSolrServer, much of the question
goes away anyway, and this JIRA will then primarily affect the leader
forwarding the updates to the followers.
Of course all bets are off if a user directly uses SUSS. Seems like a "best
practice" is use CloudSolrServer and if you really insist on NOT using it, then
this JIRA will keep you from deadlock.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
