acks=0 is a one-way send, the client doesn't need to wait on the response. Whether this is useful sort of depends on the client implementation. The new java producer does all sends async so "waiting" on a response isn't really a thing. For a client that lacks this, though, as some of them do, acks=0 will be a lot faster.
It also makes some sense in terms of what is completed when the request is considered satisfied acks = 0 - message is written to the network (buffer) acks = 1 - message is written to the leader log acks = -1 - message is committed -Jay On Sat, Jul 18, 2015 at 10:50 PM, Gwen Shapira <gshap...@cloudera.com> wrote: > Hi, > > I was looking into the different between acks = 0 and acks = 1 in the > new producer, and was a bit surprised at what I found. > > Basically, if I understand correctly, the only difference is that with > acks = 0, if the leader fails to append locally, it closes the network > connection silently and with acks = 1, it sends an actual error > message. > > Which seems to mean that with acks = 0, any failed produce will lead > to metadata refresh and a retry (because network error), while acks = > 1 will lead to either retries or abort, depending on the error. > > Not only this doesn't match the documentation, it doesn't even make > much sense... > "acks = 0" was supposed to somehow makes things "less safe but > faster", and it doesn't seem to be doing that any more. I'm not even > sure there's any case where the "acks = 0" behavior is desirable. > > Is it my misunderstanding, or did we somehow screw up the logic here? > > Gwen >
