Re: [VOTE] KIP-618: Exactly-once support for source connectors

[Chris Egerton]

Thanks Ismael.

The vote passes after 12 days with the following +1s:

- Ryanne Dolan
- Dongjin Lee
- Randall Hauch (binding)
- Tom Bentley (binding)
- Gwen Shapira (binding)

Thanks to all who voted and provided feedback.

I'd also like to thank to Gregory Harris, who has been invaluable as an
offline sounding board and has possibly contributed as much to this effort
as the rest of the discussion thread combined. Thanks Greg!

I'll update the KIP to the "Adopted" status and plan to have a
feature-complete PR up for review by the end of the week.

Cheers,

Chris

On Tue, Jun 15, 2021 at 11:17 AM Ismael Juma  wrote:

> 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  >
> 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 
> > 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 
> 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  >
> > >> 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
> >  > >> >
> > >> > 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 
> > >> 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
> > >> > >  > >> > > > >
> > >> > > > > 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

Re: [VOTE] KIP-618: Exactly-once support for source connectors

[Ismael Juma]

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 
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 
> 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  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 
> >> 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
>  >> >
> >> > 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 
> >> 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
> >> > >  >> > > > >
> >> > > > > 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*

Re: [VOTE] KIP-618: Exactly-once support for source connectors

[Chris Egerton]

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  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  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 
>> 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 > >
>> > 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 
>> wrote:
>> > >
>> > > > +1 (non-binding).
>> > > >
>> > > > Thanks,
>> > > > Dongjin
>> > > >
>> > > > On Fri, Jun 4, 2021 at 2:35 PM Ryanne Dolan 
>> > > wrote:
>> > > >
>> > > > > +1 (non-binding)
>> > > > >
>> > > > > On Thu, Jun 3, 2021, 10:23 AM Chris Egerton
>> > > > > > > >
>> > > > > 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:  github.com/dongjinleekr
>> > > > keybase:
>> > > https://keybase.io/dongjinleekr
>> > > > linkedin:
>> > > kr.linkedin.com/in/dongjinleekr
>> > > > speakerdeck:
>> > > > speakerdeck.com/dongjin
>> > > > *
>> > > >
>> > >
>> >
>>
>

Re: [VOTE] KIP-618: Exactly-once support for source connectors

[Chris Egerton]

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  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 
> 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 
> > 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  wrote:
> > >
> > > > +1 (non-binding).
> > > >
> > > > Thanks,
> > > > Dongjin
> > > >
> > > > On Fri, Jun 4, 2021 at 2:35 PM Ryanne Dolan 
> > > wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > On Thu, Jun 3, 2021, 10:23 AM Chris Egerton
> > >  > > > >
> > > > > 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:  github.com/dongjinleekr
> > > > keybase:
> > > https://keybase.io/dongjinleekr
> > > > linkedin:
> > > kr.linkedin.com/in/dongjinleekr
> > > > speakerdeck:
> > > > speakerdeck.com/dongjin
> > > > *
> > > >
> > >
> >
>

Re: [VOTE] KIP-618: Exactly-once support for source connectors

[Ismael Juma]

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 
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 
> 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  wrote:
> >
> > > +1 (non-binding).
> > >
> > > Thanks,
> > > Dongjin
> > >
> > > On Fri, Jun 4, 2021 at 2:35 PM Ryanne Dolan 
> > wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > On Thu, Jun 3, 2021, 10:23 AM Chris Egerton
> >  > > >
> > > > 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:  github.com/dongjinleekr
> > > keybase:
> > https://keybase.io/dongjinleekr
> > > linkedin:
> > kr.linkedin.com/in/dongjinleekr
> > > speakerdeck:
> > > speakerdeck.com/dongjin
> > > *
> > >
> >
>

Re: [VOTE] KIP-618: Exactly-once support for source connectors

[Gwen Shapira]

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 
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  wrote:
>
> > +1 (non-binding).
> >
> > Thanks,
> > Dongjin
> >
> > On Fri, Jun 4, 2021 at 2:35 PM Ryanne Dolan 
> wrote:
> >
> > > +1 (non-binding)
> > >
> > > On Thu, Jun 3, 2021, 10:23 AM Chris Egerton
>  > >
> > > 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:  github.com/dongjinleekr
> > keybase:
> https://keybase.io/dongjinleekr
> > linkedin:
> kr.linkedin.com/in/dongjinleekr
> > speakerdeck:
> > speakerdeck.com/dongjin
> > *
> >
>

Re: [VOTE] KIP-618: Exactly-once support for source connectors

[Tom Bentley]

Hi Chris,

Thanks for the KIP and the discussion.

+1 (binding)

Kind regards,

Tom

On Thu, Jun 10, 2021 at 4:15 AM Randall Hauch  wrote:

> +1 (binding)
>
> I still have a few minor questions/suggestions about wording (e.g., in
> JavaDoc), but those can be handled via the discussion thread and won't
> change the intent of those API methods or the KIP.
>
> Best regards,
>
> Randall
>
> On Wed, Jun 9, 2021 at 7:32 AM Chris Egerton 
> 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  wrote:
> >
> > > +1 (non-binding).
> > >
> > > Thanks,
> > > Dongjin
> > >
> > > On Fri, Jun 4, 2021 at 2:35 PM Ryanne Dolan 
> > wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > On Thu, Jun 3, 2021, 10:23 AM Chris Egerton
> >  > > >
> > > > 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:  github.com/dongjinleekr
> > > keybase:
> > https://keybase.io/dongjinleekr
> > > linkedin:
> > kr.linkedin.com/in/dongjinleekr
> > > speakerdeck:
> > > speakerdeck.com/dongjin
> > > *
> > >
> >
>

Re: [VOTE] KIP-618: Exactly-once support for source connectors

[Randall Hauch]

+1 (binding)

I still have a few minor questions/suggestions about wording (e.g., in
JavaDoc), but those can be handled via the discussion thread and won't
change the intent of those API methods or the KIP.

Best regards,

Randall

On Wed, Jun 9, 2021 at 7:32 AM Chris Egerton 
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  wrote:
>
> > +1 (non-binding).
> >
> > Thanks,
> > Dongjin
> >
> > On Fri, Jun 4, 2021 at 2:35 PM Ryanne Dolan 
> wrote:
> >
> > > +1 (non-binding)
> > >
> > > On Thu, Jun 3, 2021, 10:23 AM Chris Egerton
>  > >
> > > 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:  github.com/dongjinleekr
> > keybase:
> https://keybase.io/dongjinleekr
> > linkedin:
> kr.linkedin.com/in/dongjinleekr
> > speakerdeck:
> > speakerdeck.com/dongjin
> > *
> >
>

Re: [VOTE] KIP-618: Exactly-once support for source connectors

[Chris Egerton]

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  wrote:

> +1 (non-binding).
>
> Thanks,
> Dongjin
>
> On Fri, Jun 4, 2021 at 2:35 PM Ryanne Dolan  wrote:
>
> > +1 (non-binding)
> >
> > On Thu, Jun 3, 2021, 10:23 AM Chris Egerton  >
> > 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:  github.com/dongjinleekr
> keybase: https://keybase.io/dongjinleekr
> linkedin: kr.linkedin.com/in/dongjinleekr
> speakerdeck:
> speakerdeck.com/dongjin
> *
>

Re: [VOTE] KIP-618: Exactly-once support for source connectors

[Dongjin Lee]

+1 (non-binding).

Thanks,
Dongjin

On Fri, Jun 4, 2021 at 2:35 PM Ryanne Dolan  wrote:

> +1 (non-binding)
>
> On Thu, Jun 3, 2021, 10:23 AM Chris Egerton 
> 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:  github.com/dongjinleekr
keybase: https://keybase.io/dongjinleekr
linkedin: kr.linkedin.com/in/dongjinleekr
speakerdeck: speakerdeck.com/dongjin
*

Re: [VOTE] KIP-618: Exactly-once support for source connectors

[Ryanne Dolan]

+1 (non-binding)

On Thu, Jun 3, 2021, 10:23 AM Chris Egerton 
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
>

[VOTE] KIP-618: Exactly-once support for source connectors

[Chris Egerton]

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