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 > <mailto:moiz.ji...@gmail.com>> wrote: > Awesome. Thanks. > > On Thu, May 25, 2017 at 10:13 PM, Eron Wright <eronwri...@gmail.com > <mailto: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 > <mailto: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 > > >
