lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Khludnev (JIRA)" <>
Subject [jira] [Commented] (SOLR-3585) processing updates in multiple threads
Date Tue, 10 Jul 2012 09:07:35 GMT


Mikhail Khludnev commented on SOLR-3585:

bq. I think it would be nicer if this ...

David, please let me know what issues with current design you see?

>From my perspective UpdateRequestProcessorFactory's way advantage is pluggability, you
can cofigure one or several of them, and then you are able to choose whether to use it or
not, even in runtime e.g. cient can send small updates into regular chain, and choose parallel
chain for huge bulks, or failover during spike periods etc. 

ContentStreamHandlerBase.handleRequestBody() is had to be single threaded. Even it creates
several processor chains (which are single threaded "prototypes"), it's hard to separate content
stream onto substreams per several processing threads. Even it's possible how to make sure
that this distribution is done evenly? 
> processing updates in multiple threads
> --------------------------------------
>                 Key: SOLR-3585
>                 URL:
>             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

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message