Hi Piotr, I also think the scenario mentioned in this FLIP is useful to address. I am happy to discuss this together and figure out the more usable APIs.
I guess the choice of API pretty much depends on when users need to use it. I am assuming it is needed when using dataStream.window(...). Is there any other case that needs this feature? It is mentioned in FLINK-18647 <https://issues.apache.org/jira/browse/FLINK-18647> that we need the task thread to be blocked until the timer gets triggered on the registered time point. The JIRA and the FLIP do not seem to provide the use-case for this feature. Could you explain more about the use-cases that might need this feature? What do you think of the alternative API vs. the approach proposed in the FLIP? Maybe we can continue the discussion by detailing the pros/cons. Best, Dong On Wed, Nov 9, 2022 at 4:35 PM Piotr Nowojski <pnowoj...@apache.org> wrote: > Hi all, > > Big thanks to Yun Gao for driving this! > > > I wonder whether we need to add a new option when registering timers. > Won't > > it be sufficient to flush all pending timers on termination but not allow > > new ones to be registered? > > Maximilian, I'm sure that single semantics is not enough. All three that > are proposed here (cancel, wait, trigger immediately) were requested by > users. > > Dong, as I initially wrote in the above-mentioned ticket [1] I'm personally > open to discussions about the final shape of the API. > > Best, > Piotrek > > [1] https://issues.apache.org/jira/browse/FLINK-18647 > > wt., 8 lis 2022 o 03:42 Yun Gao <yungao...@aliyun.com.invalid> napisał(a): > > > Hi Maximilian, > > > > Thanks for the discussion! It seems there are still other kinds of > > scenarios > > that could not be flushed, like scenarios like "emit record X if record Y > > hasn't > > arrived within 30 seconds after record Z" or "fails the job if the > > external system > > does not response in 30 seconds", these timers seems should be dropped > > instead of > > triggering. Thus we think it would be necessary to provide per-timer > > configuration. > > > > Best, > > Yun Gao > > > > > > > > > > ------------------Original Mail ------------------ > > Sender:Maximilian Michels <m...@apache.org> > > Send Date:Fri Nov 4 21:35:58 2022 > > Recipients:Flink Dev <dev@flink.apache.org>, Yun Gao < > yungao...@aliyun.com > > > > > Subject:Re: [DISCUSS] FLIP-269: Properly Handling the Processing Timers > on > > Job Termination > > Hey Yun, > > > > I wonder whether we need to add a new option when registering timers. > Won't > > it be sufficient to flush all pending timers on termination but not allow > > new ones to be registered? > > > > -Max > > > > On Wed, Nov 2, 2022 at 11:20 AM Yun Gao <yungao...@aliyun.com.invalid> > > wrote: > > > > > Hi everyone, > > > I would like to open a discussion[1] on how to > > > properly handle the processing timers on job > > > termination. > > > Currently all the processing timers would be > > > ignored on job termination. This behavior is > > > not suitable for some cases like WindowOperator. > > > Thus we'd like to provide more options for how > > > to deal with the pending times on job termination, > > > and provide correct semantics on bounded stream > > > for these scenarios. The FLIP is based on the previous > > > discussion with Piotr and Divye in [2]. > > > [1] > > > > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-269%3A+Properly+Handling+the+Processing+Timers+on+Job+Termination > > > < > > > > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-269%3A+Properly+Handling+the+Processing+Timers+on+Job+Termination > > > > > > > [2] https://issues.apache.org/jira/browse/FLINK-18647 < > > > https://issues.apache.org/jira/browse/FLINK-18647 > > > > > > >
