C0urante commented on code in PR #13375:
URL: https://github.com/apache/kafka/pull/13375#discussion_r1145061560
##########
connect/runtime/src/test/java/org/apache/kafka/connect/integration/ConnectWorkerIntegrationTest.java:
##########
@@ -195,7 +197,22 @@ public void testRestartFailedTask() throws Exception {
public void testBrokerCoordinator() throws Exception {
ConnectorHandle connectorHandle =
RuntimeHandles.get().connectorHandle(CONNECTOR_NAME);
workerProps.put(DistributedConfig.SCHEDULED_REBALANCE_MAX_DELAY_MS_CONFIG,
String.valueOf(5000));
- connect = connectBuilder.workerProps(workerProps).build();
+ Properties brokerProps = new Properties();
+
+ // Find a free port and use it in the Kafka broker's listeners config.
We can't use port 0 in the listeners
+ // config to get a random free port because in this test we want to
stop the Kafka broker and then bring it
+ // back up and listening on the same port in order to verify that the
Connect cluster can re-connect to Kafka
+ // and continue functioning normally. If we were to use port 0 here,
the Kafka broker would most likely listen
+ // on a different random free port the second time it is started.
Review Comment:
Actually, the more I think about it, the more brittle this seems. We're
introducing a way to override the listeners property in the
`KafkaClusterTestKit` class, but that only works for single-node clusters, and
the use cases are fairly thin (IIUC it's not actually necessary to be able to
override the `listeners` property for tests that involve changing the security
protocols in use, which basically just leaves us with being able to reuse ports
across restarts).
I'm still not completely against this (since if used responsibly, you can
still do what you need to), but I wonder if it might be cleaner to do the
refactoring in the `KafkaClusterTestKit` class instead, both to make it
reusable and to allow for multi-node cases.
--
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: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
