mbwaheed commented on a change in pull request #1430:
URL: https://github.com/apache/lucene-solr/pull/1430#discussion_r425517306
##########
File path:
solr/core/src/java/org/apache/solr/update/processor/DistributedZkUpdateProcessor.java
##########
@@ -184,6 +186,30 @@ public void processCommit(CommitUpdateCommand cmd) throws
IOException {
updateCommand = cmd;
+ // 1. SHARED replica has a hard requirement of processing each indexing
batch with a hard commit(either explicit or
+ // implicit, HttpSolrCall#addCommitIfAbsent) because that is how, at the
end of an indexing batch, synchronous push
+ // to shared store gets hold of the segment files on local disk. SHARED
replica also does not support the notion of soft commit.
+ // Therefore unlike NRT replica type we do not need to broadcast commit to
the leaders of all the shards of a collection.
+ //
+ // 2. <code>isLeader</code> is computed fresh each time an
AddUpdateCommand/DeleteUpdateCommand belonging to the indexing
+ // batch is processed. And finally it is recomputed in this method. It is
possible that at the beginning of a batch
+ // this replica was a leader and did process some
AddUpdateCommand/DeleteUpdateCommand. But before reaching this
+ // method lost the leadership. In that case we will still like to process
the commit otherwise the indexing batch can
+ // succeed without pushing the changes to the shared store (data loss).
Therefore, we are not restricting the
Review comment:
SHARED replica does not need leadership as such because it relies on the
optimistic concurrency when writing to metadataSuffix znode. As long as a
replica can match the metadataSuffix version it started indexing with, it will
be correct. If the new leader has started indexing and have pushed before this
replica then this replica will fail. But if it pushes before the new leader can
push then the batch on new leader will fail. In both cases indexing will be
correct.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
