C0urante commented on code in PR #13424:
URL: https://github.com/apache/kafka/pull/13424#discussion_r1146278701
##########
connect/runtime/src/main/java/org/apache/kafka/connect/runtime/distributed/DistributedHerder.java:
##########
@@ -1090,6 +1090,39 @@ public void putConnectorConfig(final String connName,
final Map<String, String>
);
}
+ @Override
+ public void stopConnector(final String connName, final Callback<Void>
callback) {
+ log.trace("Submitting request to transition connector {} to STOPPED
state", connName);
+
+ addRequest(
+ () -> {
+ refreshConfigSnapshot(workerSyncTimeoutMs);
Review Comment:
We're actually fairly conservative about synchronous reads-to-end in the
tick loop; they don't take place automatically in every iteration. But yeah, I
don't think this is necessary; originally, I wanted to make sure that the
connector hadn't been deleted yet, but if it had been, this node (the leader)
would have been the one to handle that deletion request, which includes a
read-to-end afterwards.
I do want to add a forced read-to-end after we write the new target state,
though, so that the leader can correctly reject attempts to write new task
configs for the connector if it is stopped.
--
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
