[
https://issues.apache.org/jira/browse/FLINK-16876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17073520#comment-17073520
]
Andrey Zagrebin commented on FLINK-16876:
-----------------------------------------
My understanding is that event time provider for TTL will be related to the
watermark of the operators. Then the TtlTimeProvider will probably be passed to
StreamTaskStateInitializer#streamOperatorStateContext from the operators. The
environment is created outside of operators, afaik. It could only supply
processing time provider or something implemented by users for which we have
not had plans so far.
At the moment, we have only TTL with processing time which we want to mock.
StreamTaskStateInitializerImpl creates the backends and needs to give them
TtlTimeProvider for that. Currently, StreamTaskStateInitializerImpl uses a
hardcoded TtlTimeProvider.DEFAULT for that. In general, I do not see a big
problem with this approach at the moment:
> is it possible to pass the {{TtlTimeProvider}} to
>StreamTaskStateInitializerImpl constructor directly?
> Because {{AbstractStreamOperatorTestHarness}} uses
> {{StreamTaskStateInitializerImpl}}.
Later, we can refactor this.
Another idea is to use actually ProcessingTimeService#getCurrentProcessingTime
instead of TtlTimeProvider.DEFAULT in
StreamTaskStateInitializer#streamOperatorStateContext. The production
implementation of ProcessingTimeService is the same system time.
AbstractStreamOperatorTestHarness has a TestProcessingTimeService and
setProcessingTime to mock time.
> 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
>
> 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)
