[
https://issues.apache.org/jira/browse/KAFKA-17627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887374#comment-17887374
]
Greg Harris commented on KAFKA-17627:
-------------------------------------
> Why should connector be skipped when it's a part that communicates with
> sink/source?
The connector configuration already has it's TTLs processed correctly. If the
connector config includes a secret with a TTL, it will get restarted at the
appropriate time.
If processing the task configuration also restarted the connector, it would be
an additional restart that isn't necessary. Additionally, each task's
configuration is processed separately by the WorkerConfigTransformer. It would
be undesirable for task 0 to cause restarts of task N.
> ConfigProvider TTLs do not restart Tasks
> ----------------------------------------
>
> Key: KAFKA-17627
> URL: https://issues.apache.org/jira/browse/KAFKA-17627
> Project: Kafka
> Issue Type: Bug
> Components: connect
> Affects Versions: 2.0.0
> Reporter: Greg Harris
> Assignee: Spacrocket
> Priority: Major
> Labels: newbie
>
> The ConfigProvider interface allows for implementations to provide
> configurations with an accompanying Time To Live, a lifetime that the
> returned value is valid for. Callers which receive a TTL should periodically
> call the ConfigProvider to refresh and receive any updated value.
> The WorkerConfigTransformer is responsible for accepting TTLs from
> ConfigProviders, and scheduling restarts for connectors to force them to
> refresh their externalized configurations.
> Since the introduction of the ConfigProvider interface in 2.0.0, when the
> WorkerConfigTransformer processes task configurations, it schedules a restart
> of the connector, which may or may not be present on the running machine.
> Instead, when secrets for a task include a TTL, the task should be restarted
> directly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
