Page History

...

The implementation details are still not very clear at this momentevolving, and we’d like to get a clearer picture as we move on.

However, the The basic idea is very simple - TimerService and user states need to have access to each other.

• TimerService needs to access user states so that triggered timer can clean up expired user states.
• User states need to access TimerService in order to register timers when certain TtlUpdateEvent happened to user states. We can add callback functions to all state implementations to ensure that we get notified on all state accesses.

...

1. Where should the code live in? Should it live with operators, state backends, or both? We may also need something in operators or state backends (e.g. operators/StreamingRuntimeContext/KeyedStateStore) to have access to TimerService
   
   We may need to experiment and prototype before finalizing this decision.
   
   
2. How to distinguish TTL timers from user timers so that they don't interfere with each other.?
   
   we need a good strategy to ensure that the TTL timers do not interfere with user-configured timers, i.e.specifically, what happens if a user configures a timer for the same time as a Ttl timer, and which one should be invoked first? The main problem right now is that we have to distinguish between ? Upon discussion, we believe that the user-configured timer should always be invoked first. But how can we distinguish user and TTL timers. ? Currently, timer service does not support timer tags, and we may need to find a better of achieving the purpose, either adding support for timer tags (or another method) to distinguish timers.

...

1. or some other ways.

Test Plan

Normal unit, integration, and end-to-end tests

...