[GitHub] [geode] DonalEvans commented on a change in pull request #5600: GEODE-8202: Two-step serial gw sender threads start

[GitBox <gi...@apache.org>]

DonalEvans commented on a change in pull request #5600:
URL: https://github.com/apache/geode/pull/5600#discussion_r508871988



##########
File path: geode-wan/src/main/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java
##########
@@ -348,11 +349,56 @@ public void destroyConnection() {
     }
   }
 
+  Connection retryInitializeConnection(Connection con) {
+    final boolean isDebugEnabled = logger.isDebugEnabled();
+    ServerLocation server = this.sender.getServerLocation();
+    String connectedServerId = con.getEndpoint().getMemberId().getUniqueId();
+    String expectedServerId = this.processor.getExpectedReceiverUniqueId();
+    boolean connectedToExpectedReceiver = connectedServerId.equals(expectedServerId);
+    if (expectedServerId.equals("")) {
+      if (isDebugEnabled) {
+        logger.debug("First dispatcher connected to endpoint " + connectedServerId);
+      }
+      this.processor.setExpectedReceiverUniqueId(connectedServerId);
+      connectedToExpectedReceiver = true;
+    }
+    int attempt = 0;
+    final int maxAttempts = 5;

Review comment:
       When this method is invoked, do we expect that the first call to `acquireConnection()` should result in a connection to the desired server, or is there an element of randomness in which server we end up getting connected to, hence the retries? If it's the latter, this method could prove unusable for situations in which the chance of getting the correct server at random is low.

##########
File path: geode-wan/src/main/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java
##########
@@ -472,6 +516,12 @@ private GatewaySenderException getInitializeConnectionExceptionToThrow(
                 "No available connection was found, but the following active servers exist: %s",
                 buffer.toString());
       }
+      if (this.sender.getEnforceThreadsConnectSameReceiver()) {
+        if (Pattern.compile("Cannot get connection to .* after .* attempts.")

Review comment:
       This matching may fail if the exception message generated in `retryInitializeConnection()` is changed. Is there a way to prevent future changes to the code from breaking this check?




----------------------------------------------------------------
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:
users@infra.apache.org