[
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
SOLR-3585-oome-and-default-tests-chain.patch
incremental patch SOLR-3585-oome-and-default-tests-chain.patch
full patch SOLR-3585.patch is also attached.
bq. RE IOExceptions... see handleError() which does ...
I reordered lines in ThreadBurster.Runner.run(). now it passes OOME into
Callback.handleError(). CUPF.handleError() now accepts more throables.
bq. that should be clarified in comments/docs) is that the "next"
I refreshed CUPF javadoc, but rely on your sense of beauty on commit anyway
bq. Also, I think I see a bug. UPRChain.createProcessor doesn't create any URPs
prior to
it's either not a problem, or I didn't get you, I don't think I need to ...
bq. ... fix this by inserting NoOpDistributingUpdateProcessorFactory at the
head of the factories when creating the chain.
DUPF is inserted when chain is read from xml, it isn't inserted when I request
"tail-chain" remaining after CUPF.
bq. Testing: Since its semantics are aligned with default behavior,..
I added new chain named concurrent and mark it default (fortunately it's absent
so far) in solrconfig.xml and solrconfig-tlog.xml. it should impact many tests.
at least FullSolrCloudDistribCmdsTest and CloudSolrServerTest touches CUPF and
stay green.
is it enough in scope of this ticket? is it non-invasive enough? or you propose
something particular.
As a followup (separate) ticket I can propose to add/and check that CURP is
between DUPF and RUPF in UpdateRequestProcessorChain.init() and insert in
default implicit chain SolrCore.loadUpdateProcessorChains().
bq. but It's still not apparent to me the way you coded it is necessary (and I
agree on avoiding ThreadLocal). I think I'll try and change it and see if the
test breaks.
I bet LogUpdateProcessor punish you if you push it concurrently enough. see
SOLR-2694, SOLR-2804, SOLR-3484, SOLR-3314.
bq. It's also unclear why you clone the AddUpdateCommand in processAdd().
no secret here.
look how XMLLoader.processUpdate() mutates same AddUpdateCommand instance (on
every <doc> tag). It's curious that CUSS doesn't allow such way.
> 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-oome-and-default-tests-chain.patch,
> SOLR-3585.patch, SOLR-3585.patch, 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]
