Thanks Kostas. So even though the timer state is managed separately from the key state (from runtimeContext) I can safely assume both the states to be fault tolerant and maintain association with the key of the stream?
On Fri, May 26, 2017 at 1:51 PM, Kostas Kloudas <k.klou...@data-artisans.com > wrote: > Hi Moiz, > > state.clear() refers to the state that you have registered in your job, > using the getState() > from the runtimeContext. > > Timers are managed by Flink’s timer service and they are cleaned up by > Flink itself when > the job terminates. > > Kostas > > On May 26, 2017, at 6:41 AM, Moiz S Jinia <moiz.ji...@gmail.com> wrote: > > A follow on question. Since the registered timers are part of the managed > key state, do the timers get cancelled when i call state.clear()? > > Moiz > > On Thu, May 25, 2017 at 10:20 PM, Moiz S Jinia <moiz.ji...@gmail.com> > wrote: > >> Awesome. Thanks. >> >> On Thu, May 25, 2017 at 10:13 PM, Eron Wright <eronwri...@gmail.com> >> wrote: >> >>> Yes, registered timers are stored in managed keyed state and should be >>> fault-tolerant. >>> >>> -Eron >>> >>> On Thu, May 25, 2017 at 9:28 AM, Moiz S Jinia <moiz.ji...@gmail.com> >>> wrote: >>> >>>> With a checkpointed RocksDB based state backend, can I expect the >>>> registered processing timers to be fault tolerant? (along with the managed >>>> keyed state). >>>> >>>> Example - >>>> A task manager instance owns the key k1 (from a keyed stream) that has >>>> registered a processing timer with a timestamp thats a day ahead in the >>>> future. If this instance is killed, and the key is moved to another >>>> instance, will the onTimer trigger correctly on the other machine at the >>>> expected time with the same keyed state (for k1)? >>>> >>>> Thanks, >>>> Moiz >>>> >>> >>> >> > >
