[
https://issues.apache.org/jira/browse/FLINK-6491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005933#comment-16005933
]
ASF GitHub Bot commented on FLINK-6491:
---------------------------------------
Github user sunjincheng121 commented on the issue:
https://github.com/apache/flink/pull/3863
Hi @fhueske thanks a lot for your reviewing. I had update the PR. with
following changes:
* Uniform hump name, change all `qConfig` and `qConf` to `queryConfig`.
* Add warn log into `DataStreamOverAggregate`.
* Fix cleanup logic
* Extend test cases that cover the corner cases of the clean up logic.
But there are two things I have not do, that is:
* `check for processing time over range windows that
minIdleStateRetentionTime > preceding interval.`
I do not think we need add this check. Because both row-base and
time-base will be able to meet the incorrect result due to state cleanup. an
importation thing we need to do is let use know the function of the cleanup
config.
* `remove the registerEventCleanupTimer method`
The reason of I add this method is In A row-time OVER
(TimeDomain.EVENT_TIME), we always get 0 when we call
ctx.timerService.currentProcessingTime.
What do you think?
Thanks,
SunJincheng
> Add QueryConfig to specify state retention time for streaming queries
> ---------------------------------------------------------------------
>
> Key: FLINK-6491
> URL: https://issues.apache.org/jira/browse/FLINK-6491
> Project: Flink
> Issue Type: Bug
> Components: Table API & SQL
> Affects Versions: 1.3.0
> Reporter: Fabian Hueske
> Assignee: sunjincheng
> Priority: Critical
>
> By now we have a couple of streaming operators (group-windows, over-windows,
> non-windowed aggregations) that require operator state. Since state is not
> automatically cleaned-up by Flink, we need to add a mechanism to configure a
> state retention time.
> If configured, a query will retain state for a specified period of state
> inactivity. If state is not accessed within this period of time, it will be
> cleared. I propose to add two parameters for this, a min and a max retention
> time. The min retention time specifies the earliest time and the max
> retention time the latest time when state is cleared. The reasoning for
> having two parameters is that we can avoid to register many timers if we have
> more freedom when to discard state.
> This issue also introduces a QueryConfig object which can be passed to a
> streaming query, when it is emitted to a TableSink or converted to a
> DataStream (append or retraction).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
