Hi Moiz! Adding a bit of more detail here: Yes, the timer will be restored on whatever new instance is responsible for that key. There is one “gotcha” to look out for, though: the firing time of timers are absolute; what this means is that if the checkpoints timer’s firing processing timestamp is t (which is basically the registering time + configured trigger time), then it will fire also at processing timestamp t on the new instance. Therefore, you should be aware of out-of-sync clocks between the 2 instances.
Another thing to note is that if the job isn’t running at t (when the timer is supposed to fire), then on restore, that timer is fired immediately. Cheers, Gordon On 26 May 2017 at 12:44:00 AM, 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
