[ 
https://issues.apache.org/jira/browse/FLINK-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318309#comment-16318309
 ] 

Xavier Fournet commented on FLINK-3089:
---------------------------------------

I fully agree to adopt a relaxed TTL policy. In one of our Flink use cases we 
implemented TTL in a ProcessFunction. In order to avoid to register too many 
timers we are rounding the TTL expiration time : eg two events separated with 
10s can compute an expiration rounded to the same minute, so the two event will 
register the same timer, so only one timer will be really stored and processed.

So the most import for us is that:
* the context is kept at least with the given TTL
* eventually (like in eventual consistency) the context is purged after the 
given TTL in order to free resources (RAM, storage)
* we don't matter if we can access the context after the given TTL, in our case 
it will be processed as it has not expired

> State API Should Support Data Expiration (State TTL)
> ----------------------------------------------------
>
>                 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
>            Assignee: Bowen Li
>
> 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 state 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.4.14#64029)

Reply via email to