[
https://issues.apache.org/jira/browse/FLINK-5929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897829#comment-15897829
]
ASF GitHub Bot commented on FLINK-5929:
---------------------------------------
Github user sjwiesman commented on a diff in the pull request:
https://github.com/apache/flink/pull/3479#discussion_r104492162
--- Diff:
flink-streaming-java/src/main/java/org/apache/flink/streaming/runtime/operators/windowing/functions/InternalWindowFunction.java
---
@@ -39,5 +40,31 @@
* @param out A collector for emitting elements.
* @throws Exception The function may throw exceptions to fail the
program and trigger recovery.
*/
+ @Deprecated
void apply(KEY key, W window, IN input, Collector<OUT> out) throws
Exception;
--- End diff --
I noticed an issue when removing apply. The method is used inside of
AccumulatingKeyedTimePanes which takes in an AbstractStreamOperator as an
argument to its evaluateWindow method. When creating the context I can get the
global keyed state backend from the operator, but not the partitioned state
because those methods are protected. Now the only two uses of this class are
its subclasses which have both been deprecated. My question is, do you think I
should modify the evaluateWindow method to accept a keyed state store which
wraps the operator partitioned state or just throw an exception on
context.windowState() because all valid uses of this method have been
deprecated?
> 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)
