Thanks, Guowei, I see your point.
But I'm afraid there is no direct connection between delivery semantics and
TimeService.
Yes, obviously, Java Timer is the first thing that comes to mind, but it
requires an extra thread to perform background work, this approach inflicts
some drawbacks such as
Hi,
AFAIK, TimeService in Flink could guarantee the semantics of "at least
once/exactly once" after failure.
If you only want to reload config periodically I think you could use Java
native Timer yourself.
Best,
Guowei
Guowei Ma 于2019年4月28日周日 上午9:25写道：
> Hi
> AFAIK, TimeService is Flink could
Hi
AFAIK, TimeService is Flink could guarantee the semastics of
Best,
Guowei
Mikhail Pryakhin 于2019年4月26日周五 下午7:57写道：
> Hi David,
> Thank you!
>
> Yes, fair enough, but take for instance a BucketingSink class[1], it is a
> RichFunction which employs Timeservice to execute time-based logic, whic
Hi David,
Thank you!
Yes, fair enough, but take for instance a BucketingSink class[1], it is a
RichFunction which employs Timeservice to execute time-based logic, which is
not directly associated with an event flow, like for example closing files
every n minutes, etc. In an AsyncFunction I int
Hi Mike,
I think the reason why there is no access to TimerService in async
function is that as it is an async function, there are no guarantees
when/and where(at which stage of the pipeline) the function will
actually be executed. This characteristic doesn't align with
TimerService and timely cal
Hello, Flink community!
It happens that I need to access a timer service in a RichAsyncFunction
implementation. I know it's normally accomplished via StreamingRuntimeContext
instance available in a RichFunction, but unfortunately, RichAsyncFunction
extending RichFunction overrides “setRuntimeCo
