[
https://issues.apache.org/jira/browse/SOLR-8500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15128647#comment-15128647
]
Erick Erickson commented on SOLR-8500:
--------------------------------------
Oh, _that_ kind of reorder....
As it happens, in this case the volume is so high that they...er...well, can't
recover a replica if it gets out of sync, they have to wait for the indexing
for that time slice to stop and do a full sync.
None of which matters, I see Yonik is making progress on 8586 so I'll just
wait. My reminder entry is tireless in bringing up that I should look at this
JIRA....
> Allow the number of threads ConcurrentUpdateSolrClient StreamingSolrClients
> configurable by a system property
> -------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-8500
> URL: https://issues.apache.org/jira/browse/SOLR-8500
> Project: Solr
> Issue Type: Improvement
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Minor
> Attachments: SOLR-8500.patch
>
>
> Despite the warning in that code, in extremely high throughput situations
> where there are guaranteed to be no updates to existing documents, it can be
> useful to have more than one runner.
> I envision this as an "expert" kind of thing, used only in situations where
> the a-priori knowledge is that there are no updates to existing documents.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
