[
https://issues.apache.org/jira/browse/FLINK-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953254#comment-15953254
]
Aljoscha Krettek commented on FLINK-3089:
-----------------------------------------
Setting a new timer does not erase a previous timer, only when you set a timer
for the same timestamp will no additional timer be created. I think it's quite
hard to actually remove existing timers, for the current (queue based) approach
I think its an {{O(n)}} operation and for on-disk data structures it would get
even more expensive.
There is some work on putting the timers in RocksDB: FLINK-5544. That would
solve the issue with very large amounts of timers.
> State API Should Support Data Expiration
> ----------------------------------------
>
> Key: FLINK-3089
> URL: https://issues.apache.org/jira/browse/FLINK-3089
> Project: Flink
> Issue Type: New Feature
> Components: DataStream API, State Backends, Checkpointing
> Reporter: Niels Basjes
>
> In some usecases (webanalytics) there is a need to have a state per visitor
> on a website (i.e. keyBy(sessionid) ).
> At some point the visitor simply leaves and no longer creates new events (so
> a special 'end of session' event will not occur).
> The only way to determine that a visitor has left is by choosing a timeout,
> like "After 30 minutes no events we consider the visitor 'gone'".
> Only after this (chosen) timeout has expired should we discard this state.
> In the Trigger part of Windows we can set a timer and close/discard this kind
> of information. But that introduces the buffering effect of the window (which
> in some scenarios is unwanted).
> What I would like is to be able to set a timeout on a specific OperatorState
> value which I can update afterwards.
> This makes it possible to create a map function that assigns the right value
> and that discards the state automatically.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
