[ 
https://issues.apache.org/jira/browse/SOLR-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032023#comment-14032023
 ] 

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 bonus.

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: 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, 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]

Reply via email to