You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Ishan Chattopadhyaya (JIRA)" <ji...@apache.org> on 2015/10/09 08:21:26 UTC

[jira] [Created] (SOLR-8148) Ensure that updates are not reordered

Ishan Chattopadhyaya created SOLR-8148:
------------------------------------------

             Summary: Ensure that updates are not reordered
                 Key: SOLR-8148
                 URL: https://issues.apache.org/jira/browse/SOLR-8148
             Project: Solr
          Issue Type: Improvement
            Reporter: Ishan Chattopadhyaya


There was discussion in SOLR-5944 (and possibly elsewhere) on exploring ensuring that updates are not reordered when sent from leader to replica. This would simplify a lot of things. 

Here's Yonik's comment from SOLR-5944:

Don't reorder updates between leader and replicas:

*    create a new ConcurrentUpdateSolrClient that uses a single channel and can return individual responses... perhaps this fits into HTTP/2 ?
*    have only a single SolrClient on the leader talk to each replica
    order the udpates in _version_ order when sending
**        prob multiple ways to achieve this... reserve a slot when getting the version, or change versions so that they are contiguous so we know if we are missing one.

The only additional reason to use multiple threads when sending is to increase indexing performance. We can also implement multi-threading for increased parallelism on the server side. This should also simplify clients (no more batching, multiple threads, etc), as well as make our general recovery system more robust.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org