[
https://issues.apache.org/jira/browse/GEODE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17217981#comment-17217981
]
ASF GitHub Bot commented on GEODE-8202:
---------------------------------------
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:
us...@infra.apache.org
> New option for serial gw sender threads start when receivers share ip and port
> ------------------------------------------------------------------------------
>
> Key: GEODE-8202
> URL: https://issues.apache.org/jira/browse/GEODE-8202
> Project: Geode
> Issue Type: Improvement
> Reporter: Alberto Bustamante Reyes
> Assignee: Alberto Bustamante Reyes
> Priority: Major
> Labels: pull-request-available
>
> RFC:
> [https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start|https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
