murblanc commented on a change in pull request #2179:
URL: https://github.com/apache/lucene-solr/pull/2179#discussion_r552220473



##########
File path: 
solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java
##########
@@ -254,8 +280,27 @@ public void call(ClusterState clusterState, ZkNodeProps 
message, @SuppressWarnin
       }
 
       shardRequestTracker.processResponses(results, shardHandler, false, null, 
Collections.emptySet());
+
+      if (withCollection != null) {
+        // process replica placements for the secondary collection, if any are 
needed
+        for (ReplicaPosition replicaPosition : replicaPositions) {
+          if (!replicaPosition.collection.equals(withCollection)) {
+            continue;
+          }
+          ZkNodeProps props = new ZkNodeProps(
+              Overseer.QUEUE_OPERATION, ADDREPLICA.toString(),
+              ZkStateReader.COLLECTION_PROP, replicaPosition.collection,
+              ZkStateReader.SHARD_ID_PROP, replicaPosition.shard,
+              "node", replicaPosition.node,
+              CommonAdminParams.WAIT_FOR_FINAL_STATE, 
Boolean.TRUE.toString()); // set to true because we want `withCollection` to be 
ready after this collection is created
+          new AddReplicaCmd(ocmh).call(clusterState, props, results);
+          clusterState = zkStateReader.getClusterState(); // refresh

Review comment:
       You know this call does absolutely nothing, right?
   
   Good news is there's not need to refresh, not here and not in the other 
places where it's done.
   
   When Collection API calls wait for something, they repeatedly read the in 
memory cluster state (maintained by ZkStateReader) until they observe the 
desired change. When they do it means that 1. the Overseer applied the change 
in ZK (directly as a cluster state change or as a side effect of a Collection 
API call itself doing a cluster state change as is the case here), and 2. the 
zookeeper watches that this node has on its cluster state did fire and the 
update from Zookeeper was applied to the cluster state.
   It does happen that currently Collection API commands run on the Overseer 
node where the cluster state updater runs, but really the two are independent 
and could well be running on different nodes.




----------------------------------------------------------------
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

Reply via email to