Yes, that is correct. Kostas
> On May 26, 2017, at 11:05 AM, Moiz S Jinia <moiz.ji...@gmail.com> wrote: > > 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 > <mailto: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 >> <mailto: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 >> >> >> > >
