timoninmaxim commented on a change in pull request #8206:
URL: https://github.com/apache/ignite/pull/8206#discussion_r487743667
##########
File path:
modules/core/src/main/java/org/apache/ignite/internal/client/thin/ReliableChannel.java
##########
@@ -473,6 +415,196 @@ public void addChannelFailListener(Runnable chFailLsnr) {
chFailLsnrs.add(chFailLsnr);
}
+ /** Should the channel initialization be stopped. */
+ private boolean stopInitCondition() {
+ return scheduledChannelsReinit.get() || closed;
+ }
+
+ /**
+ * Init channel holders to all nodes.
+ * @param force enable to replace existing channels with new holders.
+ */
+ private synchronized void initChannelHolders(boolean force) {
+ // enable parallel threads to schedule new init of channel holders
+ scheduledChannelsReinit.set(false);
+
+ if (!force && channels.get() != null)
+ return;
+
+ Set<InetSocketAddress> resolvedAddrs =
parseAddresses(clientCfg.getAddresses());
Review comment:
With StatefulSet it will be a static configuration, i.e. list of DNS
names like "ignite-1, ignite-2, ignite-3". Also it's not prohibited to
configure with DNS names in any other env (non-k8s).
`TcpClientChannel` creates socket with `cfg.getAddress().getHostName()` and
it invokes reverse lookup even in case we specify address with hostnames.
Kubernetes have troubles with reverse lookup, as pods aren't aimed to be
reverse resolved at all. There are some work in that direction, but the issue
isn't resolved yet: https://github.com/coredns/coredns/issues/3888
So, I think we can't rely on this reverse lookup. So it could be case when
DNS name isn't changed but the channel is broken and don't have changes to be
fixed. So re-resolution is required.
I will check that resolved address isn't changed. And so skip next steps.
----------------------------------------------------------------
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:
[email protected]