Hi all, Firstly, thanks for the votes!
Secondly--Ismael, in response to your feedback, I have to admit I'm a little in the dark here. Are you suggesting that there be a new Kafka API for the act of fencing out a producer with a given transactional ID (or set of transactional IDs)? If so, can you highlight the advantages of this new API over the existing INIT_PRODUCER_ID API? At least as far as Connect is concerned, we likely wouldn't be able to fully leverage any newly-introduced Kafka APIs in the release that they first appear, since we'd want to maintain compatibility with older broker versions. One could argue that since this feature is entirely opt-in we could make it a requirement for users to upgrade their Kafka clusters to 3.0 (or whatever version supports this new API) in order to leverage it, but given the effectiveness of the INIT_PRODUCER_ID API in servicing our needs, I'm not sure that would be the right tradeoff. And as far as the distinction between client- and broker-side (or rather, transaction coordinator-side) logic goes, I'm having trouble envisioning anything--with or without a new Kafka API--that would make the client-side logic simpler; the existing proposal only involves a find coordinator request and then an init producer request; is there a simpler way to handle things client-side that plays nicely with established idioms for the admin and Kafka APIs? I plan to leave the vote thread open as long as there are unresolved comments from serious contributors such as Ismael, and close it as soon as those are all taken care of. Cheers, Chris On Thu, Jun 10, 2021 at 11:05 AM Ismael Juma <ism...@juma.me.uk> wrote: > One concern I have is that we are not introducing a request for the fencing > and implementing that logic in the admin client directly. I would prefer a > request in the txn coordinator with the right semantics. > > Ismael > > On Thu, Jun 10, 2021, 7:46 AM Gwen Shapira <g...@confluent.io.invalid> > wrote: > > > I'm supportive of the feature and the interface details discussed in the > > discussion thread. I just want to clarify that I'm voting for the last > > version discussed in the thread - that includes two phase upgrade and no > > breaking changes in 3.0. > > > > +1 (binding) > > > > > > On Wed, Jun 9, 2021, 5:32 AM Chris Egerton <chr...@confluent.io.invalid> > > wrote: > > > > > Hi all, > > > > > > Friendly reminder that the KIP freeze is today; please cast your votes > if > > > you'd like to see this feature introduced in time for 3.0. > > > > > > Cheers, > > > > > > Chris > > > > > > On Mon, Jun 7, 2021 at 1:49 AM Dongjin Lee <dong...@apache.org> wrote: > > > > > > > +1 (non-binding). > > > > > > > > Thanks, > > > > Dongjin > > > > > > > > On Fri, Jun 4, 2021 at 2:35 PM Ryanne Dolan <ryannedo...@gmail.com> > > > wrote: > > > > > > > > > +1 (non-binding) > > > > > > > > > > On Thu, Jun 3, 2021, 10:23 AM Chris Egerton > > > <chr...@confluent.io.invalid > > > > > > > > > > wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > I'd like to call for a vote on KIP-618, which adds support for > > > > > exactly-once > > > > > > delivery guarantees for source connectors in the Kafka Connect > > > > framework. > > > > > > > > > > > > I suspect there might be a little more discussion to be had but > > with > > > > the > > > > > > KIP freeze deadline approaching, I wanted to give anyone > following > > > > along > > > > > > the chance to cast a +1 as soon as they feel that we've gotten > to a > > > > > > reasonable state. > > > > > > > > > > > > The KIP: > > > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-618%3A+Exactly-Once+Support+for+Source+Connectors > > > > > > > > > > > > The discussion thread: > > > > > > > > > > > > > > > > > > > > > > > > > > > https://mail-archives.apache.org/mod_mbox/kafka-dev/202005.mbox/%3CCAMdOrUX-VK5OSB3OOdJNXW_YKEJH9FjQZ4eyzr2GXUhSeDnF3Q%40mail.gmail.com%3E > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Chris > > > > > > > > > > > > > > > > > > > > > > > -- > > > > *Dongjin Lee* > > > > > > > > *A hitchhiker in the mathematical world.* > > > > > > > > > > > > > > > > *github: <http://goog_969573159/>github.com/dongjinleekr > > > > <https://github.com/dongjinleekr>keybase: > > > https://keybase.io/dongjinleekr > > > > <https://keybase.io/dongjinleekr>linkedin: > > > kr.linkedin.com/in/dongjinleekr > > > > <https://kr.linkedin.com/in/dongjinleekr>speakerdeck: > > > > speakerdeck.com/dongjin > > > > <https://speakerdeck.com/dongjin>* > > > > > > > > > >
