[ 
https://issues.apache.org/jira/browse/FLINK-5929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907483#comment-15907483
 ] 

ASF GitHub Bot commented on FLINK-5929:
---------------------------------------

Github user aljoscha commented on a diff in the pull request:

    https://github.com/apache/flink/pull/3479#discussion_r105662139
  
    --- Diff: 
flink-streaming-java/src/main/java/org/apache/flink/streaming/api/functions/windowing/FoldApplyProcessWindowFunction.java
 ---
    @@ -92,12 +93,45 @@ public void process(K key, final Context context, 
Iterable<T> values, Collector<
                        result = foldFunction.fold(result, val);
                }
     
    -           windowFunction.process(key, windowFunction.new Context() {
    +           ProcessWindowFunction<ACC, R, K, W>.Context ctx = 
windowFunction.new Context() {
    --- End diff --
    
    This can benefit from a similar refactoring as the internal window 
functions, i.e. creating an internal context class instead of the anonymous 
inner classes.
    
    This also holds for `FoldApplyProcessAllWindowFunction`, 
`ReduceApplyProcessAllWindowFunction` and `ReduceApplyProcessWindowFunction`.


> 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)

Reply via email to