You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Jorge Esteban Quilcate Otoya <qu...@gmail.com> on 2022/02/15 19:16:28 UTC
[VOTE] KIP-820: Extend KStream process with new Processor API
Hi all,
I'd like to start a vote on KIP-820 which proposes extending KStream to use
the new Processor API
https://cwiki.apache.org/confluence/display/KAFKA/KIP-820%3A+Extend+KStream+process+with+new+Processor+API
Thanks,
Jorge
Re: [VOTE] KIP-820: Extend KStream process with new Processor API
Posted by Jorge Esteban Quilcate Otoya <qu...@gmail.com>.
Hi Dev team,
The vote for KIP-820 has passed with:
3 +1 (binding) votes from John, Matthias, and Guozhang.
This KIP is now accepted. Thanks for your feedback and votes!
Jorge.
On Thu, 17 Mar 2022 at 17:30, Guozhang Wang <wa...@gmail.com> wrote:
> Reviewed the updated docs, and recasting my +1 vote again, thanks Jorge for
> pushing it through!
>
> Guozhang
>
> On Tue, Mar 15, 2022 at 4:28 PM Matthias J. Sax <mj...@apache.org> wrote:
>
> > +1 (binding)
> >
> > Thanks for pushing this through. Was a difficult discussion!
> >
> >
> > -Matthias
> >
> > On 3/15/22 10:01 AM, John Roesler wrote:
> > > Thanks for the update, Jorge!
> > >
> > > I’m still +1 (binding)
> > >
> > > Thanks,
> > > John
> > >
> > > On Thu, Feb 17, 2022, at 12:57, Guozhang Wang wrote:
> > >> Thanks Jorge, overall looks good to me.
> > >>
> > >> Maybe we can clarify a bit in the wiki that the reason we have to not
> > >> include the additional `final String... stateStoreNames` params in the
> > new
> > >> `process` API is that we need to have overloaded functions which takes
> > >> `ProcessorSupplier<...> ` where the output types are not `Void`, but
> > due to
> > >> type eraser we cannot distinguish the new overloaded function
> signatures
> > >> with the old ones if they also include `final String...
> > stateStoreNames`.
> > >> And in javadocs explains that if users want to connect state stores to
> > this
> > >> processor, they could use the `connectState` API instead.
> > >>
> > >> Otherwise, I'm +1.
> > >>
> > >> Guozhang
> > >>
> > >> On Tue, Feb 15, 2022 at 11:54 AM John Roesler <vv...@apache.org>
> > wrote:
> > >>
> > >>> Thanks, Jorge!
> > >>>
> > >>> I'm +1 (binding)
> > >>>
> > >>> -John
> > >>>
> > >>> On Tue, 2022-02-15 at 19:16 +0000, Jorge Esteban Quilcate
> > >>> Otoya wrote:
> > >>>> Hi all,
> > >>>>
> > >>>> I'd like to start a vote on KIP-820 which proposes extending KStream
> > to
> > >>> use
> > >>>> the new Processor API
> > >>>>
> > >>>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-820%3A+Extend+KStream+process+with+new+Processor+API
> > >>>>
> > >>>> Thanks,
> > >>>> Jorge
> > >>>
> > >>>
> > >>
> > >> --
> > >> -- Guozhang
> >
>
>
> --
> -- Guozhang
>
Re: [VOTE] KIP-820: Extend KStream process with new Processor API
Posted by Guozhang Wang <wa...@gmail.com>.
Reviewed the updated docs, and recasting my +1 vote again, thanks Jorge for
pushing it through!
Guozhang
On Tue, Mar 15, 2022 at 4:28 PM Matthias J. Sax <mj...@apache.org> wrote:
> +1 (binding)
>
> Thanks for pushing this through. Was a difficult discussion!
>
>
> -Matthias
>
> On 3/15/22 10:01 AM, John Roesler wrote:
> > Thanks for the update, Jorge!
> >
> > I’m still +1 (binding)
> >
> > Thanks,
> > John
> >
> > On Thu, Feb 17, 2022, at 12:57, Guozhang Wang wrote:
> >> Thanks Jorge, overall looks good to me.
> >>
> >> Maybe we can clarify a bit in the wiki that the reason we have to not
> >> include the additional `final String... stateStoreNames` params in the
> new
> >> `process` API is that we need to have overloaded functions which takes
> >> `ProcessorSupplier<...> ` where the output types are not `Void`, but
> due to
> >> type eraser we cannot distinguish the new overloaded function signatures
> >> with the old ones if they also include `final String...
> stateStoreNames`.
> >> And in javadocs explains that if users want to connect state stores to
> this
> >> processor, they could use the `connectState` API instead.
> >>
> >> Otherwise, I'm +1.
> >>
> >> Guozhang
> >>
> >> On Tue, Feb 15, 2022 at 11:54 AM John Roesler <vv...@apache.org>
> wrote:
> >>
> >>> Thanks, Jorge!
> >>>
> >>> I'm +1 (binding)
> >>>
> >>> -John
> >>>
> >>> On Tue, 2022-02-15 at 19:16 +0000, Jorge Esteban Quilcate
> >>> Otoya wrote:
> >>>> Hi all,
> >>>>
> >>>> I'd like to start a vote on KIP-820 which proposes extending KStream
> to
> >>> use
> >>>> the new Processor API
> >>>>
> >>>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-820%3A+Extend+KStream+process+with+new+Processor+API
> >>>>
> >>>> Thanks,
> >>>> Jorge
> >>>
> >>>
> >>
> >> --
> >> -- Guozhang
>
--
-- Guozhang
Re: [VOTE] KIP-820: Extend KStream process with new Processor API
Posted by "Matthias J. Sax" <mj...@apache.org>.
+1 (binding)
Thanks for pushing this through. Was a difficult discussion!
-Matthias
On 3/15/22 10:01 AM, John Roesler wrote:
> Thanks for the update, Jorge!
>
> I’m still +1 (binding)
>
> Thanks,
> John
>
> On Thu, Feb 17, 2022, at 12:57, Guozhang Wang wrote:
>> Thanks Jorge, overall looks good to me.
>>
>> Maybe we can clarify a bit in the wiki that the reason we have to not
>> include the additional `final String... stateStoreNames` params in the new
>> `process` API is that we need to have overloaded functions which takes
>> `ProcessorSupplier<...> ` where the output types are not `Void`, but due to
>> type eraser we cannot distinguish the new overloaded function signatures
>> with the old ones if they also include `final String... stateStoreNames`.
>> And in javadocs explains that if users want to connect state stores to this
>> processor, they could use the `connectState` API instead.
>>
>> Otherwise, I'm +1.
>>
>> Guozhang
>>
>> On Tue, Feb 15, 2022 at 11:54 AM John Roesler <vv...@apache.org> wrote:
>>
>>> Thanks, Jorge!
>>>
>>> I'm +1 (binding)
>>>
>>> -John
>>>
>>> On Tue, 2022-02-15 at 19:16 +0000, Jorge Esteban Quilcate
>>> Otoya wrote:
>>>> Hi all,
>>>>
>>>> I'd like to start a vote on KIP-820 which proposes extending KStream to
>>> use
>>>> the new Processor API
>>>>
>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-820%3A+Extend+KStream+process+with+new+Processor+API
>>>>
>>>> Thanks,
>>>> Jorge
>>>
>>>
>>
>> --
>> -- Guozhang
Re: [VOTE] KIP-820: Extend KStream process with new Processor API
Posted by John Roesler <vv...@apache.org>.
Thanks for the update, Jorge!
I’m still +1 (binding)
Thanks,
John
On Thu, Feb 17, 2022, at 12:57, Guozhang Wang wrote:
> Thanks Jorge, overall looks good to me.
>
> Maybe we can clarify a bit in the wiki that the reason we have to not
> include the additional `final String... stateStoreNames` params in the new
> `process` API is that we need to have overloaded functions which takes
> `ProcessorSupplier<...> ` where the output types are not `Void`, but due to
> type eraser we cannot distinguish the new overloaded function signatures
> with the old ones if they also include `final String... stateStoreNames`.
> And in javadocs explains that if users want to connect state stores to this
> processor, they could use the `connectState` API instead.
>
> Otherwise, I'm +1.
>
> Guozhang
>
> On Tue, Feb 15, 2022 at 11:54 AM John Roesler <vv...@apache.org> wrote:
>
>> Thanks, Jorge!
>>
>> I'm +1 (binding)
>>
>> -John
>>
>> On Tue, 2022-02-15 at 19:16 +0000, Jorge Esteban Quilcate
>> Otoya wrote:
>> > Hi all,
>> >
>> > I'd like to start a vote on KIP-820 which proposes extending KStream to
>> use
>> > the new Processor API
>> >
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-820%3A+Extend+KStream+process+with+new+Processor+API
>> >
>> > Thanks,
>> > Jorge
>>
>>
>
> --
> -- Guozhang
Re: [VOTE] KIP-820: Extend KStream process with new Processor API
Posted by Guozhang Wang <wa...@gmail.com>.
Thanks Jorge, overall looks good to me.
Maybe we can clarify a bit in the wiki that the reason we have to not
include the additional `final String... stateStoreNames` params in the new
`process` API is that we need to have overloaded functions which takes
`ProcessorSupplier<...> ` where the output types are not `Void`, but due to
type eraser we cannot distinguish the new overloaded function signatures
with the old ones if they also include `final String... stateStoreNames`.
And in javadocs explains that if users want to connect state stores to this
processor, they could use the `connectState` API instead.
Otherwise, I'm +1.
Guozhang
On Tue, Feb 15, 2022 at 11:54 AM John Roesler <vv...@apache.org> wrote:
> Thanks, Jorge!
>
> I'm +1 (binding)
>
> -John
>
> On Tue, 2022-02-15 at 19:16 +0000, Jorge Esteban Quilcate
> Otoya wrote:
> > Hi all,
> >
> > I'd like to start a vote on KIP-820 which proposes extending KStream to
> use
> > the new Processor API
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-820%3A+Extend+KStream+process+with+new+Processor+API
> >
> > Thanks,
> > Jorge
>
>
--
-- Guozhang
Re: [VOTE] KIP-820: Extend KStream process with new Processor API
Posted by John Roesler <vv...@apache.org>.
Thanks, Jorge!
I'm +1 (binding)
-John
On Tue, 2022-02-15 at 19:16 +0000, Jorge Esteban Quilcate
Otoya wrote:
> Hi all,
>
> I'd like to start a vote on KIP-820 which proposes extending KStream to use
> the new Processor API
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-820%3A+Extend+KStream+process+with+new+Processor+API
>
> Thanks,
> Jorge