On the producer side, are you using ack=0? Earlier, ack=0 is the same as ack=1, which means that the producer has to wait for the message to be received by the leader. More recently, we did the actual implementation of ack=0, which means the producer doesn't wait for the message to reach the leader and therefore it is much faster.
On Mon, Mar 4, 2013 at 12:01 PM, Chris Curtin <[EMAIL PROTECTED]>wrote:
Am I reading the code correctly that in SyncProducerConfig.scala the DefaultRequiredAcks is 0? Thus not waiting on the leader?
Setting: props.put("request.required.acks", "1"); causes the writes to go back to the performance I was seeing before yesterday.
Are you guys open to changing the default to be 1? The MongoDB Java-driver guys made a similar default change at the end of last year because many people didn't understand the risk that the default value of no-ack was putting 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.
On Tue, Mar 5, 2013 at 1:00 AM, Jun Rao <[EMAIL PROTECTED]> wrote:
Hi Chris, setting the ack default to 1 would mean folks would have to have a replica setup and configured otherwise starting a server from scratch from download would mean an error message to the user. I hear your risk of not replicating though perhaps such a use case would be solved through auto discovery or some other feature/contribution for 0.9.
I would be -1 on changing the default right now because new folks coming in on a build either as new or migrations simply leaving because they got an error or even running by just git clone ./sbt package and running (less steps in 0.8). There are already expectations on 0.8 we should try to keep things 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 general communications to the community we can reduce risk.
ack=0: producer waits until the message is in the producer's socket buffer ack=1: producer waits until the message is received by the leader ack=-1: producer waits until the message is committed
The tradeoffs are:
ack=0: lowest latency; some data loss during broker failure ack=1: lower latency; a few data loss during broker failure ack=-1: low latency; no data loss during broker failure
All cases work with replication factor 1, which is the default setting out of box. With ack=1/-1, the producer may see some error when the leader hasn't been being elected. However, the number of errors should be small since typically leaders are elected very quickly.
The argument for making the default ack 0 is that (1) this is the same behavior 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 you better reliability.
I am not sure what's the best thing to do that here since correct setting really depends on the application. What do people feel?
Jun On Tue, Mar 5, 2013 at 6:36 AM, Joe Stein <[EMAIL PROTECTED]> wrote:
My take on this is that since 0.8 is very new, most people are going to be on 0.7 for a while. When those people try out Kafka 0.8, it is best if they see performance/guarantees similar to 0.7. Gradually, people are going to want to move to 0.8 which is when we can revisit changing the default num acks to 1.
Thanks, Neha On Tue, Mar 5, 2013 at 8:30 AM, Chris Curtin <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation project and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext