dajac commented on code in PR #22512:
URL: https://github.com/apache/kafka/pull/22512#discussion_r3421552752
##########
clients/src/main/java/org/apache/kafka/clients/NetworkClient.java:
##########
@@ -1140,8 +1140,11 @@ private void handleInitiateApiVersionRequests(long now) {
int nodeId = Integer.parseInt(node);
// In order to allow separate connections to coordinators,
the client uses large positive node ID values
// (Integer.MAX_VALUE - nodeId) for these connections
which do not match the target broker's actual node ID.
- // To avoid those, only check if the node ID is less than
half of Integer.MAX_VALUE.
- if (clusterId != null && nodeId >= 0 && nodeId <
Integer.MAX_VALUE / 2) {
+ // We can get the real node ID by subtracting from
Integer.MAX_VALUE.
+ if (nodeId > Integer.MAX_VALUE / 2) {
Review Comment:
The coordinator id is just the broker id of the broker hosting the
coordinator. Hence, it should usually be low, say < 100000. However, I agree
with @rajinisivaram that this is not documented anywhere. Honestly, I don't
like the `MAX - id` hack at all. I wonder if we should rather fix the
underlying issue which is that we limit the number of connections by node id.
Could you have a way to tell the network client that we want a connection which
is not limited by the maximum number of connections allowed? I haven't check
how feasible it it though.
My understanding is also that the connection to the group coordinator won't
have the nodeId set which is also weird from a design perspective.
--
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]
