On the producer side, are you using ack=0? Earlier, ack=0 is the same asack=1, which means that the producer has to wait for the message to bereceived by the leader. More recently, we did the actual implementation ofack=0, which means the producer doesn't wait for the message to reach theleader and therefore it is much faster.

Am I reading the code correctly that in SyncProducerConfig.scala theDefaultRequiredAcks is 0? Thus not waiting on the leader?

Setting: props.put("request.required.acks", "1"); causes the writes to goback to the performance I was seeing before yesterday.

Are you guys open to changing the default to be 1? The MongoDB Java-driverguys made a similar default change at the end of last year because manypeople didn't understand the risk that the default value of no-ack wasputting them in until they had a node failure. So they default to 'safe'and let you decide what your risk level is vs. assuming you can lose data.

Hi Chris, setting the ack default to 1 would mean folks would have to havea replica setup and configured otherwise starting a server from scratchfrom download would mean an error message to the user. I hear your riskof not replicating though perhaps such a use case would be solved throughauto discovery or some other feature/contribution for 0.9.

I would be -1 on changing the default right now because new folks coming inon a build either as new or migrations simply leaving because they got anerror or even running by just git clone ./sbt package and running (lesssteps in 0.8). There are already expectations on 0.8 we should try to keepthings settling too.

Lastly, folks when they run and go live often will have a chef, cfengine,puppet, etc script for configuration

Perhaps through some more operation documentation, comments and generalcommunications to the community we can reduce risk.

All cases work with replication factor 1, which is the default setting outof box. With ack=1/-1, the producer may see some error when the leaderhasn't been being elected. However, the number of errors should be smallsince typically leaders are elected very quickly.

The argument for making the default ack 0 is that (1) this is the samebehavior you get in 0.7 and (2) the producer runs fastest in this mode.

The argument for making the default ack 1 or -1 is that they gave youbetter reliability.

I am not sure what's the best thing to do that here since correct settingreally depends on the application. What do people feel?

My take on this is that since 0.8 is very new, most people are going to beon 0.7 for a while. When those people try out Kafka 0.8, it is best if theysee performance/guarantees similar to 0.7. Gradually, people are going towant to move to 0.8 which is when we can revisit changing the default numacks to 1.