...

• acks=0
  • If set to zero then the producer will not wait for any acknowledgment from the server at all.
• acks=1
  • This will mean the leader will write the record to its local log but will respond without awaiting full acknowledgement from all followers.
• acks=all(-1)
  • This means the leader will wait for the full set of in-sync replicas to acknowledge the record.
• acks=min.insync.replicas(-2)
  • This means the leader will wait for the min.insync.replicas number of replicas to acknowledge the record. The min.insync.replicas config can be defined in broker or topic (if overridden in topic level)

Proposed Changes

When the producer sets acks=min.insync.replicas and send a record to the broker, the broker will do the same thing as acks=all did, firstly check if current number of in-sync replicas is greater or equal to min.insync.replicas value, if not, throw NotEnoughReplicasException. If yes, we wait for the number of min.insync.replicas acknowledge, and then respond to the producers.

...

If producer is in the old version, depending on the client validation, the acks=min.insync.replicas(-2) might work not or might not work. In Java producer, it will throw ConfigException due to invalid value (-2).

...

1. Allowing acks set to a random value.
   → This is rejected because the random value might exceed the number of replicas, For example, if replication factor is 3, setting acks=4 doesn't make sense. Also, it might break the broker min.insync.replicas contract. For example, if broker set min.insync.replicas to 2, and acks=3, this will let write failure when in-sync replicas only have 2, while it reaches min.insync.replicas requirement. So I think allowing acks=min.insync.replicas makes more sense.