• Motivation: 

Until Kafka 0.8.2, if a producer wanted to make sure a message was persisted at a specific number of replicas (N) before an "ack" was returned from the broker, they would specify request.required.acks=N. This was a bit misleading since specifying request.required.acks=2 would not actually protect against data loss in all cases.

...

In this KIP we propose to remove support of  request.required.acks > 1 and return an error message to producers which request that. 

New or Changed Public Interfaces

We will stop accepting request.required.acks > 1 from clients implementing the new version of the protocol and may return a new error code.

Proposed Change

...

ProducerRequest protocol version will be bumped to 1.

...

If ProduceRequest version = 0, we will maintain current behavior, and log a WARN message in the broker about use of deprecated number of acks.

...

We will stop accepting request.required.acks > 1 from clients implementing the new version of the protocol and may return a new error code.

...

Migration Plan, Compatibility and Deprecation

Users upgrading to clients that implement new version of protocol will need to change their configuration and avoid request.required.acks >1. 

• Deprecation:

We will support existing behavior and version 0 of the protocol for 0.8.X versions. I suggest deprecating for 0.9.

Rejected Alternatives

...

Instead of bumping protocol version and adding an error, silently replace request.required.acks>1 with request.required.acks=-1. Rejected as possibly very confusing to users who will see higher latency (and possibly lower reliability) with no explanation.

Questions that may need more debate

...

• • When do we want to deprecate the existing behavior?
  • Is the error message of the right granularity? We can be more generic and use InvalidRequestParameters instead. It will allow using it for additional validations, but makes troubleshooting on client more complex.