showuon commented 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
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: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
