C0urante commented on code in PR #13375:
URL: https://github.com/apache/kafka/pull/13375#discussion_r1150909068


##########
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:
   Correct me if I'm wrong, but there doesn't seem to be a case yet that 
requires overriding the `listeners` property that can't also be addressed by 
leaving that property as-is and only touching the 
`listener.security.protocol.map` property, except for reusing ports across 
restarts.
   
   So yes, although it's possible to override `listeners` to set up SASL/SSL, 
this isn't required, and IMO it's actually cleaner if you do things by altering 
the security protocol map instead.



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

Reply via email to