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: [email protected]
For additional commands, e-mail: [email protected]
