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]