[
https://issues.apache.org/jira/browse/SOLR-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14028315#comment-14028315
]
David Smiley commented on SOLR-3585:
------------------------------------
[~mkhludnev] I disagree! I think it's crazy that to load Solr faster you have
to make it a client-side concern to know how many threads are a suitable number
to transmit data.
* Unless you are using ConcurrentUpdateSolrServer then you have to write this
concurrent code yourself as well as anybody else out there that is in the same
boat; yet doing it Solr side does it once for everyone.
* I argue it isn't the client's concern to know the ideal number of threads to
load Solr fastest. Clients don't tell Solr how big Lucene's indexing RAM
buffer should be. Should it know how many threads are on the box and how
concurrent its IO hardware is?
* Putting it Solr-side affords the possibility that configuring the threads
might be changed dynamically.
> processing updates in multiple threads
> --------------------------------------
>
> Key: SOLR-3585
> URL: https://issues.apache.org/jira/browse/SOLR-3585
> Project: Solr
> Issue Type: Improvement
> Components: update
> Affects Versions: 4.0-ALPHA, 5.0
> Reporter: Mikhail Khludnev
> Attachments: SOLR-3585.patch, SOLR-3585.patch, multithreadupd.patch,
> report.tar.gz
>
>
> Hello,
> I'd like to contribute update processor which forks many threads which
> concurrently process the stream of commands. It may be beneficial for users
> who streams many docs through single request.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
