It's different because it changes whether the client waits for the response from the broker at all. Take a look at NetworkClient.handleCompletedSends, which fills in dummy responses when a response is not expected (and that flag gets set via Sender.produceRequest using acks != 0 as a flag to ClientRequest). This means that the producer will invoke the callback & resolve the future as soon as the request hits the TCP buffer on the client. At that point, the behavior of the broker wrt generating a response doesn't matter -- the client isn't waiting on that response anyway.
This definitely is faster since you aren't waiting for the round trip, but it seems like it is of questionable value with the new producer as Jay explained. It is slightly better than just assuming records have been sent as soon as you call Producer.send() in this shouldn't trigger a callback until the records have made it through the internal KafkaProducer buffering. But since it still has to make it through the TCP buffers it doesn't really guarantee anything that useful. -Ewen On Sun, Jul 26, 2015 at 1:40 PM, Gwen Shapira <gshap...@cloudera.com> wrote: > 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 > >> > -- Thanks, Ewen
