lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Commented] (SOLR-3585) processing updates in multiple threads
Date Sun, 15 Jun 2014 21:22:02 GMT


David Smiley commented on SOLR-3585:

That's an excellent point.  In fact, anyone using ConcurrentUpdateSolrServer (CUSS) doesn't,
in effect, get the benefit of the updateLog either.

I think Solr should try to retain the same semantics one gets without using CUSS:  Once you
close out the HTTP message you send to Solr (which on one extreme might be one document or
an another a virtually endless stream of documents), that a successful HTTP response semantically
means whatever you did is "safe" -- in the updateLog at least.  If there is no updateLog then
there is no guarantee (there never was before this proposal either) and it'll return as soon
as it gets into the indexed ramBuffer (beyond text analysis).  At least then if there's a
schema related problem with Solr accepting the document then you'll know.  It would be nice
if the response could include any errors on a per-document basis (by id); but that'd be a

I doubt you'd be able to easily re-use the CUSS logic in this implementation.  I wish I had
time to partake -- sounds like fun :-)

> processing updates in multiple threads
> --------------------------------------
>                 Key: SOLR-3585
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: update
>    Affects Versions: 4.0-ALPHA, 5.0
>            Reporter: Mikhail Khludnev
>         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 was sent by Atlassian JIRA

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

View raw message