showuon edited a comment on pull request #11691:
URL: https://github.com/apache/kafka/pull/11691#issuecomment-1041473036
@mimaison , do you mean:
So, do you mean, we have some different cases:
1. if user **doesn't** set enable.idempotence explicitly: the idempotent
producer is **only enabled** when the acks=all, otherwise, disable idempotence
ex: a. `enable.idempotence` unset && `acks` unset => enable idempotence
(this was the intent behind the 3.0 change I think)
b. `enable.idempotence` unset && `acks=all` => enable idempotence
(obviously)
c. `enable.idempotence` unset && `acks!=all` => disable idempotence
(the case we tried to protect)
2. if user enable/disable enable.idempotence explicitly, we follow current
config validation to throw exceptions when bad config set,
ex: a. `enable.idempotence=true` && `acks=all` => enable idempotence
(obviously)
b. `enable.idempotence=false` => disable idempotence
c. `enable.idempotence=true` && `acks!=all` => throw exception
And we only do some special check for `acks` because many users would change
this config. For `retries` and `max.in.flight.requests.per.connection`, we
still follow current config validation no matter `enable.idempotence` is set
explicitly or not.
Does this what you mean?
If so, I'm +1. Actually, if the `retries` and
`max.in.flight.requests.per.connection` also have the same special check, I
also think it makes sense. The purpose is try not to break existing producers
after upgrade, which is good.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
