> section states:
> > > >
> > > > "If the connector generated excessive tasks after being reconfigured,
> > > then
> > > > any existing tasks for the connector will be allowed to continue
> > running,
> > > > unless tha
gt; > > unless that existing set of tasks also exceeds the tasks.max property."
> > >
> > > Would not failing the connector land us in the second scenario of
> > > 'Rejected Alternatives'?
> > >
> > > From: dev@kafka.apache.org At: 11/11/23 00:2
he connector will be allowed to continue running,
> > unless that existing set of tasks also exceeds the tasks.max property."
> >
> > Would not failing the connector land us in the second scenario of
> > 'Rejected Alternatives'?
> >
> > From: dev@kafka.apache
ed to continue running,
> unless that existing set of tasks also exceeds the tasks.max property."
>
> Would not failing the connector land us in the second scenario of
> 'Rejected Alternatives'?
>
> From: dev@kafka.apache.org At: 11/11/23 00:27:44 UTC-5:00To:
> dev@kafka.a
tinue running, unless
that existing set of tasks also exceeds the tasks.max property."
Would not failing the connector land us in the second scenario of 'Rejected
Alternatives'?
From: dev@kafka.apache.org At: 11/11/23 00:27:44 UTC-5:00To:
dev@kafka.apache.org
Subject: [DISCUSS] KIP-100
Hi all,
I'd like to open up KIP-1004 for discussion:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1004%3A+Enforce+tasks.max+property+in+Kafka+Connect
As a brief summary: this KIP proposes that the Kafka Connect runtime start
failing connectors that generate a greater number of tasks
