[
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. CUSS: have only one constructor
done. shutdownExecutor left in CUSS only that removes constructor mess.
bq. the user of ThreadBurster should simply subclass ThreadBurster and
implement the handle(), finish() and handleError() methods.
the motivation of introducing Callback is to have single thread delegate. It's
not necessary for CUSS (where stateless http client is used). But update
processors shouldn't be shared across threads. if we go the way you propose we
need to keep update processor chains in ThreadLocal, which I'm not really happy
about.
bq.making more fields on ThreadBurster private, adding some convenience methods
for adding & polling
done. it seems better now
bq. This wasn't introduced by you but runnerLock is weird
Let me keep unaware of the legacy. Let's fight them later.
bq. ThreadedUpdateProcesor.processRollback() shouldn’t call checkTrouble()
logically - yes, formally - might not so straightforward. here is the plain
scenario: correct update w/o commit; then send request with wrong update and
rollback, thus exception should prevent rollback, however if we don't
checkTrouble() before processRollback() it rollbacks the first correct update
request, and it's not what is expected. Of course, this case is subtle, and
artificial. I'm ready to accept your approach, if you confirm. I reordered rows
there so far.
bq. I wonder if there’s a nicer way to hook this in without a new
“backing.chain” param?
Indeed! I just realized how to do that, it's little bit fragile, but it looks
better
bq. I like your tests, particularly the use of DelayProcessorFactory.
Thanks. I have who to learn from.
bq. If you do it in postClose; it should be safe.
ok. thanks. now it halts running threads by shutdownNow(), I suppose it's
correct.
bq. I don’t care for some of the variable names..
Reasonable. Sorry for "blah" coding. fixed and applied CUSS names
bq. have to do a blockUntilFinished which effects other concurrent streams the
client...need to be aware there is a buffer-per-concurrent-connection...
even if it's possible to solve I don't think it's a point
bq. It’s worth documenting that DistributedUpdateProcessorFactory ought to be
before
added javadoc
bq. Masking all exceptions as IOException..
This is what I don't really get. Where it is? Isn't it another one legacy
other improvements
* renamed to ConcurrentUpdateProcessorFactory and props to mimics CUSS
* I keep passing logger to ThreadBurster to keep logs informative, are you
happy with it?
* do you like the name ThreadBurster?
* I reviewed CUSS descendants SafeConcurrentUpdateSolrServer and
StreamingSolrServers they should work fine.
> 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,
> 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]
