xiangfu0 commented on code in PR #18700:
URL: https://github.com/apache/pinot/pull/18700#discussion_r3403254957


##########
pinot-core/src/main/java/org/apache/pinot/core/transport/QueryRouter.java:
##########
@@ -151,9 +151,11 @@ private void markQueryFailed(long requestId, 
ServerRoutingInstance serverRouting
 
   public boolean hasChannel(ServerInstance serverInstance) {
     if (_serverChannelsTls != null) {
-      return 
_serverChannelsTls.hasChannel(serverInstance.toServerRoutingInstance(TableType.OFFLINE,
 true));
+      return _serverChannelsTls.hasChannel(

Review Comment:
   Same compatibility regression here: `hasChannel()`/`connect()` used to 
tolerate servers without a TLS port when the broker preferred TLS. After this 
change they hard-require `NETTY_TLS`, so mixed-version clusters can no longer 
probe or preconnect those servers. This needs the same per-server fallback as 
the deprecated boolean overload.



##########
pinot-core/src/main/java/org/apache/pinot/core/routing/LogicalTableRouteInfo.java:
##########
@@ -98,13 +98,15 @@ public Map<ServerRoutingInstance, InstanceRequest> 
getRequestMap(long requestId,
 
     Map<ServerRoutingInstance, InstanceRequest> requestMap = new HashMap<>();
 
+    ServerInstance.RoutingType routingType =

Review Comment:
   This drops the old `preferTls` fallback semantics. The deprecated boolean 
overload only used TLS when the server actually advertised a TLS port; this 
`NETTY_TLS` path now throws for any server that has not rolled out TLS yet. In 
a mixed cluster, a TLS-enabled broker will start failing route construction 
instead of falling back to plain Netty. Please preserve the per-server fallback 
here (or add an explicit `PREFER_NETTY_TLS` routing mode) before switching 
callers over.



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

Reply via email to