I wanted to bring this up before the First Stable release and see what other people think. The methods I’m talking about are:
void deleteTimer(StateNamespace namespace, String timerId, TimeDomain timeDomain); @Deprecated void deleteTimer(StateNamespace namespace, String timerId); @Deprecated void deleteTimer(TimerData timerKey); The last two are slated for deletion. Notice that the first one doesn’t take the timestamp of the timer to delete, which implies that there is only one active timer per namespace/timerId/timeDomain. These are my motivations for removal: - Timer removal is difficult and has varying levels of support on different Runners and varying levels of cost. - Removing the interface now and adding it back later is easy. Having it in the FSR and later removing it is quite hard. I can only speak about the internal Flink implementation where Timers are on a Heap (Java Priority Queue). Here removal is quite expensive, see, for example this ML thread: https://lists.apache.org/thread.html/ac4d8e36360779a9b5047cf21303222980015720aac478e8cf632216@%3Cuser.flink.apache.org%3E. Especially this part: I thought I would drop my opinion here maybe it is relevant. We have used the Flink internal timer implementation in many of our production applications, this supports the Timer deletion but the deletion actually turned out to be a huge performance bottleneck because of the bad deletion performance of the Priority queue. In many of our cases deletion could have been avoided by some more clever registration/firing logic and we also ended up completely avoiding deletion and instead using "tombstone" markers by setting a flag in the state which timers not to fire when they actually trigger. Gyula Note that in Flink it’s not possible to delete a timer if you don’t know the timestamp. Other systems might store timers in more elaborate data structures (hierarchical timer wheels come to mind) where it’s also hard to delete a timer without knowing the timestamp. If we decide to keep timer removal in the user API there’s the possibility to simulate timer removal by keeping the timestamp of the currently active timer for a given timerID and checking a firing timer against that. Best, Aljoscha
