[
https://issues.apache.org/jira/browse/FLINK-16876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071635#comment-17071635
]
Yun Tang commented on FLINK-16876:
----------------------------------
[~azagrebin] From my point of view, the different ttl time provider could be
mapped to different {{StreamTimeCharacteristic}} set in
{{StreamExecutionEnvironment}}. Therefore, I plan to add new interfaces of
getter and setter for {{TtlTimeProvider}} in {{StreamExecutionEnvironment}} and
pass them to {{StreamConfig}} with newly added filed "ttlTimeProvider". By
doing this, we could decouple the ttl time provider from state backend.
FLINK-16581 focus on state TTL check on mini batch duplication, which means its
PR would have to verify the state has been expired after TTL. However, since we
hard code {{TtlTimeProvider.DEFAULT}} to create the state backend, the UTs in
that PR has to [wait for some while after TTL
passed|https://github.com/apache/flink/pull/11482/files#diff-c530b499d8d892a5b9b623f57c10b575R87]
which is definitely not so good in UT implementation.
> Make TtlTimeProvider configurable when creating keyed state backend
> -------------------------------------------------------------------
>
> Key: FLINK-16876
> URL: https://issues.apache.org/jira/browse/FLINK-16876
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / State Backends
> Affects Versions: 1.10.0
> Reporter: Yun Tang
> Priority: Major
> Fix For: 1.11.0
>
>
> Currently, we would always use TtlTimeProvider.DEFAULT to create keyed state
> backend. This is somehow acceptable since we only support processing time for
> TTL now. However, this would make UT tests which would verify TTL logic not
> so convenient like FLINK-16581.
> I propose to let TtlTimeProvider configurable when creating keyed state
> backend to not block other feature development.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
