[SOLR-8148] Ensure that updates are not reordered

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Assignee: Unassigned
• Reporter: Ishan Chattopadhyaya
• Created: 09/Oct/15 06:20
• Updated: 09/Oct/15 06:21

Description

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.

Issue Links

• relates to: SOLR-5944 Support updates of numeric DocValues