[
https://issues.apache.org/jira/browse/FLINK-5929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15887731#comment-15887731
]
ASF GitHub Bot commented on FLINK-5929:
---------------------------------------
GitHub user uce opened a pull request:
https://github.com/apache/flink/pull/3427
[FLINK-5929] [tests] Fix SavepointITCase instability
When shutting down the testing cluster it could happen that checkpoint
files lingered around (for checkpoints independent of the savepoint).
This commit deactives checkpointing for the test and uses count down
latches to track progress, which also reduces the test time.
I've triggered multiple Travis builds. I will merge this if they build
without the `SavepointITCase` failing.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/uce/flink 5923-savepoint_it_case
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/flink/pull/3427.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #3427
----
commit e0c46f34f55bfee743236c4042be4b2501436811
Author: Ufuk Celebi <u...@apache.org>
Date: 2017-02-28T10:13:28Z
[FLINK-5929] [tests] Fix SavepointITCase instability
When shutting down the testing cluster it can happen that checkpoint
files lingered around (checkpoints independent of the savepoint).
This commit deactives checkpointing for the test and uses count down
latches to track progress, which also reduces the test time.
----
> Allow Access to Per-Window State in ProcessWindowFunction
> ---------------------------------------------------------
>
> Key: FLINK-5929
> URL: https://issues.apache.org/jira/browse/FLINK-5929
> Project: Flink
> Issue Type: Improvement
> Components: DataStream API
> Reporter: Aljoscha Krettek
>
> Right now, the state that a {{WindowFunction}} or {{ProcessWindowFunction}}
> can access is scoped to the key of the window but not the window itself. That
> is, state is global across all windows for a given key.
> For some use cases it is beneficial to keep state scoped to a window. For
> example, if you expect to have several {{Trigger}} firings (due to early and
> late firings) a user can keep state per window to keep some information
> between those firings.
> The per-window state has to be cleaned up in some way. For this I see two
> options:
> - Keep track of all state that a user uses and clean up when we reach the
> window GC horizon.
> - Add a method {{cleanup()}} to {{ProcessWindowFunction}} which is called
> when we reach the window GC horizon that users can/should use to clean up
> their state.
> On the API side, we can add a method {{windowState()}} on
> {{ProcessWindowFunction.Context}} that retrieves the per-window state and
> {{globalState()}} that would allow access to the (already available) global
> state. The {{Context}} would then look like this:
> {code}
> /**
> * The context holding window metadata
> */
> public abstract class Context {
> /**
> * @return The window that is being evaluated.
> */
> public abstract W window();
> /**
> * State accessor for per-key and per-window state.
> */
> KeyedStateStore windowState();
> /**
> * State accessor for per-key global state.
> */
> KeyedStateStore globalState();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
