[
https://issues.apache.org/jira/browse/SOLR-8500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119930#comment-15119930
]
Mark Miller edited comment on SOLR-8500 at 1/27/16 6:25 PM:
------------------------------------------------------------
No, I don't think we should allow config that we know will break the system,
whether it's fast or not. If correctness does not matter, we can make things
really fast.
Once Yonik finishes the peer sync finger print it should no longer be a
correctness issue to have these reorders though.
was (Author: [email protected]):
No, I don't think we should allow config to what we know will break the system,
whether it's fat or not. If correctness does not matter, we can make things
really fast.
Once Yonik finishes the peer sync finger print it should no longer be a
correctness issue to have these reorders though.
> 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]
