[
https://issues.apache.org/jira/browse/SOLR-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-3585:
-----------------------------------
Attachment: SOLR-3585.patch
bq. I think Solr should try to retain the same semantics one gets without using
CUSS...
it's a well reasoning!
bq. I doubt you'd be able to easily re-use the CUSS logic in this
implementation.
why.. it's just a few clicks in Refactoring menu.
Check the scratch attached.
- I introduced oddly-named ThreadBurster, where CUSS concurrency logic has been
moved;
- I moved CUSS and ThreadedUpdateProcessorFactory onto ThreadBurster. It seems
work.
out of scope so far:
- a few CUSS descendants, which is more strict in error handling, but they
should be able to live on ThreadBurster as well as TUP
- naming is completely mad, feel free to contribute a better taste ones
- it's TUP left from the earlier patch, I wish to revamp it to make it seems
more like CUSS
Your feedback is quite appreciated.
> 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, 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]
