For enable.idempotence=safe, it seems giving user impression that idempotence would be safe.
However, since it really means best effort, the 'safety' is debatable. Why not just call the new mode besteffort ? Cheers On Tue, Sep 5, 2017 at 11:24 AM, Ismael Juma <ism...@juma.me.uk> wrote: > If we add the message format version (a topic config) in the response of > TopicMetadata, we should consider adding the max message bytes as well. > That would allow us to later improve the implementation of KIP-126 to split > the batch _before_ sending. > > Ismael > > On Tue, Sep 5, 2017 at 7:17 PM, Jason Gustafson <ja...@confluent.io> > wrote: > > > The proposal looks good. Two minor comments: > > > > 1. Can we call out how we handle the duplicate case? This is a change in > > behavior since we currently raise OutOfOrderSequence in this case. > > > > 2. Instead of passing through `idempotenceLevel` in the ProduceRequest, I > > wonder if we should have a field for the minimum required message format. > > When using enable.idempotence=required, we could set the minimum required > > version to v2. For enable.idempotence=requested, we could use v0. The > > advantage is that we may find other uses for a more general field in the > > future. Alternatively, maybe we really should be returning the message > > format version of each topic in the TopicMetadata response. A nice bonus > of > > doing so is that it gives the producer the ability to craft the right > > format version ahead of time and avoid the need for conversion on the > > broker. > > > > Thanks, > > Jason > > > > On Tue, Aug 29, 2017 at 4:32 PM, Apurva Mehta <apu...@confluent.io> > wrote: > > > > > Hi, > > > > > > In the discussion of KIP-185 (enable idempotence by default), we > > discovered > > > some shortcomings of the existing idempotent producer implementation. > > > Fixing these issues requires changes to the ProduceRequest and > > > ProduceResponse protocols as well as changes to the values of the > > > 'enable.idempotence' producer config. > > > > > > Hence, I split off those changes into another KIP so as to decouple the > > two > > > issues. Please have a look at my follow up KIP below: > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > > > 192+%3A+Provide+cleaner+semantics+when+idempotence+is+enabled > > > > > > KIP-185 depends on KIP-192, and I hope to make progress on the latter > > > independently. > > > > > > Thanks, > > > Apurva > > > > > >
