t;
> > >> > >>>> > >>>>>> Hi All
> > >> > >>>> > >>>>>>
> > >> > >>>> > >>>>>> Our use case is that we need to process elements for
> the
>
> >>>> > filip.karni...@gmail.com>
> >> > >>>> > >>>>> wrote:
> >> > >>>> > >>>>>
> >> > >>>> > >>>>>> Hi All
> >> > >>>> > >>>>>>
> &g
t; >>>> > >>>>>> Hi All
>> > >>>> > >>>>>>
>> > >>>> > >>>>>> Our use case is that we need to process elements for the
>> same
>> > >>>> key
>> > >>>> >
ocess any
> > >>>> > >>>>>> further messages for that key, until a retry succeeds or a
> > >>>> human
> > >>>> > sends a
> > >>>> > >>>>>> 'skip' comman
sends a
> >>>> > >>>>>> 'skip' command message.
> >>>> > >>>>>>
> >>>> > >>>>>> diagram:
> >>>> > >>>>>>
> >>>> >
> >>>>
> https://mer
sSeQpKjkv7j_buQ5tjAV4YeehOHHyQDsLAF1HbXCCyQZKB-2CTyzUOCjqUygHNBZPdxljW2MAoEaU6u0mMfGNPGqHBZJb1piasmFKlMmqxd7cqj3Dqbu0DNdfwHTGoek
>>>> > >>>>>> mermaid (in case mermaid.live goes down in the future):
>>>> > >>>>>> graph LR
mermaid (in case mermaid.live goes down in the future):
>>> > >>>>>> graph LR
>>> > >>>>>> incoming[incoming events] --> job(Flink statefun job)
>>> > >>>>>> commands[commands] -->|skip| job
>>> > &
t; |async puts/gets with side effects| other(other
>> > >>>>>> systems)
>> > >>>>>>
>> > >>>>>> Having the processing happen outside of Flink is nice-to-have
>> from
>> > an
>> > >>>>>> independent scalab
;>>> So long story short - no cyclic messaging, but also no way I can
> > >>>>>> think of to use existing native Flink operators like async i/o
> > (which when
> > >>>>>> I last checked a few years back didn't have access to keyed state)
> > &g
> >>>>>> I last checked a few years back didn't have access to keyed state)
> >>>>>>
> >>>>>>
> >>>>>> P.S. Please note that there is already a pull request that has
> >>>
d a few years back didn't have access to keyed state)
>>>>>>
>>>>>>
>>>>>> P.S. Please note that there is already a pull request that has
>>>>>> something to do wtih Flink 1.15, albeit without a description or a jira:
>>>&
t;
>>>>>
>>>>> On Wed, 26 Oct 2022 at 19:54, Galen Warren
>>>>> wrote:
>>>>>
>>>>>> Hi Gordon (and others),
>>>>>>
>>>>>> I'm also using this project for stateful messaging, including
>>>
> On Wed, 26 Oct 2022 at 19:54, Galen Warren
>>>> wrote:
>>>>
>>>>> Hi Gordon (and others),
>>>>>
>>>>> I'm also using this project for stateful messaging, including messaging
>>>>> among functions.
ing this project for stateful messaging, including messaging
>>>> among functions.
>>>>
>>>> I've contributed a small amount of code in the past and have also
>>>> enabled
>>>> Flink 1.15 compatibility in a local fork, so
>>
>>> Thanks,
>>> Galen
>>>
>>> On Wed, Oct 26, 2022 at 1:34 PM Ken Krugler >> >
>>> wrote:
>>>
>>> > Hi Gordon,
>>> >
>>> > We’re using it for stateful messaging, and also calling remote
>>&
t;>
>> On Wed, Oct 26, 2022 at 1:34 PM Ken Krugler
>> wrote:
>>
>> > Hi Gordon,
>> >
>> > We’re using it for stateful messaging, and also calling remote
>> > Python-based functions.
>> >
>> > So yes, also very interested i
in the future.
> >
> > — Ken
> >
> >
> >
> > > Begin forwarded message:
> > >
> > > From: "Tzu-Li (Gordon) Tai"
> > > Subject: Re: Stateful Functions with Flink 1.15 and onwards
> > > Date: October 26, 2022 at
Ken
>
>
>
> > Begin forwarded message:
> >
> > From: "Tzu-Li (Gordon) Tai"
> > Subject: Re: Stateful Functions with Flink 1.15 and onwards
> > Date: October 26, 2022 at 10:25:26 AM PDT
> > To: dev@flink.apache.org
> > Reply-To: dev@flink.apache.or
Subject: Re: Stateful Functions with Flink 1.15 and onwards
> Date: October 26, 2022 at 10:25:26 AM PDT
> To: dev@flink.apache.org
> Reply-To: dev@flink.apache.org
>
> Hi Filip,
>
> Thanks for bringing this up.
>
> The hard truth is that committers who were previously acti
Hi Filip,
Thanks for bringing this up.
The hard truth is that committers who were previously active on the
StateFun subproject, including myself, all currently have other focuses.
Indeed, we may need to discuss with the community on how to proceed if
there seems to be no continued committer cover
As far as I know the original authors are not working on this
implementation anymore. Other folks might be able to provide more context.
Instead of rewriting your code to be a native Flink job, would it be an
option for your team to pick up the pull request to port statefun to Flink
1.15?
-Max
O
Hi, I noticed that the development on stateful functions has come to a bit
of a halt, with a pull request to update statefun to use Flink 1.15 being
in the `open` state since May 2022.
What do we think is the future of this sub-project?
The background to this question is that my team is on a shar
22 matches
Mail list logo
