Thanks for the votes everyone. One of the proposals here was to raise a 'DuplicateSequenceException' to the user if the broker detected that one of the internal retries resulted in the duplicate, and the metadata for the original batch was no longer cached.
However, when implementing this change, I realized that this is quite unintuitive from the user's point of view. In reality, the 'duplicate' is only due to internal retries -- something that the user has no visibility into. And secondly, this is not an error: the batch has been persisted, only the cached metadata has been lost. I think the better approach is to return the a 'success' but make it clear that there is no record metadata. If the user tries to access `RecordMetadata.offset` or `RecordMetadata.timestamp` methods of the returned metadata, we can raise a 'NoMetadataAvailableException' or something like that. This way users who don't access the 'offset' and 'timestamp' fields would not notice a change. For the users who do, the offset and timestamp will not silently be invalid: they will be notified through an exception. This seems like the cleanest way forward and I would like to make this small change to the KIP. Does anybody have any objections? Thanks, Apurva On Thu, Sep 7, 2017 at 9:44 PM, Apurva Mehta <apu...@confluent.io> wrote: > Thanks for the comments Ismael. > > I have gone ahead and incorporated all your suggestions in the KIP > document. You convinced me on adding max.message.bytes :) > > Apurva > > On Thu, Sep 7, 2017 at 6:12 PM, Ismael Juma <ism...@juma.me.uk> wrote: > >> Thanks for the KIP. +1 (binding) from me. A few minor comments: >> >> 1. We should add a note to the backwards compatibility section explaining >> the impact of throwing DuplicateSequenceException (a new exception) from >> `send`. As I understand it, it's not an issue, but good to include it in >> the KIP. >> >> 2. For clarity, it's good to highlight in some way the new fields in the >> protocol definition itself >> >> 3. I understand that you decided not to add max.message.bytes because it's >> unrelated to this KIP. I'll try to persuade you that we should, but it's >> not a blocker if you don't agree. The reasons are: 1. The implementation >> effort to add it is minimal since it's a topic config like message format >> version, 2. It's clearly beneficial for the producer to have that >> information, 3. It's compact (just a number), 4. It's nice to avoid >> another >> protocol bump for a small change like that. >> >> Thanks, >> Ismael >> >> On Thu, Sep 7, 2017 at 9:51 PM, Apurva Mehta <apu...@confluent.io> wrote: >> >> > Hi, >> > >> > I'd like to start a vote for KIP-192: >> > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP- >> > 192+%3A+Provide+cleaner+semantics+when+idempotence+is+enabled >> > >> > Thanks, >> > Apurva >> > >> > >
