Chris updated the KIP to explain that this new Admin API behaves the same as `Producer.initTransactions`, so that seems fine to me (i.e. I withdraw my concern). I didn't review the whole KIP and since there are enough votes, I'll leave it to you all.
Ismael On Tue, Jun 15, 2021 at 5:59 AM Chris Egerton <chr...@confluent.io.invalid> wrote: > Hi Ismael, > > Friendly reminder that your comment is the only outstanding one. If I don't > hear back soon I'll probably close the KIP and we can address any concerns > in a follow-up KIP. > > Cheers, > > Chris > > On Thu, Jun 10, 2021 at 12:13 PM Chris Egerton <chr...@confluent.io> > wrote: > > > 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>* > >> > > > > >> > > > >> > > >> > > >
