[
https://issues.apache.org/jira/browse/SOLR-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409790#comment-13409790
]
Mikhail Khludnev commented on SOLR-3585:
----------------------------------------
David,
Beside of the subj. I can't get your point. Solr indeed (almost) already has _a
kind of_ "a configurable number of threads that pull Documents off of a common
incoming queue". This "queue" is a servlet container's pool, and request
buffer. But if you want to have different number of threads in indexing pool
and let's say for searching you can try to deploy solr war twice bind to
different connectors.
In this model a client have to be multithreaded, otherwise it will wait for
every <add><doc>..</doc></add> response. if it sends many docs in a single huge
sequence it looses concurrency again.
I'm not getting what's unfair in StreamingUpdateSolrServer? It's just a low
level REST impl detail or we can rephrase it as S(t)AX vs DOM style of
coding/thinking. Any client even telnet and stdio is able to form a stream of
<doc>..</doc> which will be consequently processed an the server side.
> 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
> Reporter: Mikhail Khludnev
> Priority: Minor
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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
