stillalex commented on code in PR #1504:
URL: https://github.com/apache/solr/pull/1504#discussion_r1162791455
##########
solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java:
##########
@@ -331,7 +342,7 @@ protected boolean versionAdd(AddUpdateCommand cmd) throws
IOException {
boolean isReplayOrPeersync =
(cmd.getFlags() & (UpdateCommand.REPLAY | UpdateCommand.PEER_SYNC)) !=
0;
- boolean leaderLogic = isLeader && !isReplayOrPeersync;
+ boolean leaderLogic =
leaderLogicWithVersionIntegrityCheck(isReplayOrPeersync, versionOnUpdate);
Review Comment:
> f there is some race condition causing the client to route to us (a new
sub-shard) before we know that we are ready to accept it, I'd rather not
pretend we are ready in any way.
this is what I am struggling with. I'm not convinced this can be called a
race condition on the client side. the test currently picks an http client and
issues a request. this can land on a recovering shard split. I am ok with only
having the exception in place (no subShardLeader funny business), but then the
test's request will fail, who needs to be responsible for the retry?
> Maybe throw an exception like INVALID_STATE that should cause
CloudSolrClient to retry
I agree with this idea, but I think it also hints at replacing existing test
clients with CloudSolrClient, the existing HttpSolrClient does not perform
retries.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
