What bugs me is that even with acks = 0, the broker will append to local log before responding (unless I'm misreading the code), so I don't see why a client with acks = 0 will be any faster. Unless the client chooses to not wait for response, which is orthogonal to acks parameter.
On Mon, Jul 20, 2015 at 8:52 AM, Jay Kreps <j...@confluent.io> wrote: > 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 >>
