flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fhueske <...@git.apache.org>
Subject [GitHub] flink pull request #3191: [FLINK-5529] [FLINK-4752] [docs] Improve / extends...
Date Thu, 26 Jan 2017 16:32:14 GMT
Github user fhueske commented on a diff in the pull request:

    https://github.com/apache/flink/pull/3191#discussion_r98028299
  
    --- Diff: docs/dev/windows.md ---
    @@ -692,30 +708,39 @@ input
     
     ## Triggers
     
    -A `Trigger` determines when a window (as formed by the `WindowAssigner`) is ready to
be
    +A `Trigger` determines when a window (as formed by the *window assigner*) is ready to
be
     processed by the *window function*. Each `WindowAssigner` comes with a default `Trigger`.

     If the default trigger does not fit your needs, you can specify a custom trigger using
`trigger(...)`.
     
    -The trigger interface provides five methods that react to different events: 
    +The trigger interface has five methods that allow a `Trigger` to react to different events:
     
     * The `onElement()` method is called for each element that is added to a window. 
     * The `onEventTime()` method is called when  a registered event-time timer fires. 
     * The `onProcessingTime()` method is called when a registered processing-time timer fires.

     * The `onMerge()` method is relevant for stateful triggers and merges the states of two
triggers when their corresponding windows merge, *e.g.* when using session windows. 
     * Finally the `clear()` method performs any action needed upon removal of the corresponding
window. 
     
    -Any of these methods can be used to register processing- or event-time timers for future
actions. 
    +Two things to notice about the above methods are:
    +
    +1) The first three can return a `TriggerResult`, *i.e.* take action as a response to
their corresponding event. The action can be one of the following: 
    +* `CONTINUE`: do nothing, 
    +* `FIRE`: trigger the computation, 
    +* `PURGE`: clear the elements in the window, and 
    +* `FIRE_AND_PURGE`: take both previous actions.
    +
    +2) Any of these methods can be used to register processing- or event-time timers for
future actions. 
     
     ### Fire and Purge
     
    -Once a trigger determines that a window is ready for processing, it fires. This is the
signal for the window operator to emit the result of the current window. Given a window with
a `WindowFunction` 
    +Once a trigger determines that a window is ready for processing, it fires, *i.e.*, it
returns `FIRE` or `FIRE_AND_PURGE`. This is the signal for the window operator 
    +to emit the result of the current window. Given a window with a `WindowFunction` 
     all elements are passed to the `WindowFunction` (possibly after passing them to an evictor).

     Windows with `ReduceFunction` of `FoldFunction` simply emit their eagerly aggregated
result. 
     
     When a trigger fires, it can either `FIRE` or `FIRE_AND_PURGE`. While `FIRE` keeps the
contents of the window, `FIRE_AND_PURGE` removes its content.
     By default, the pre-implemented triggers simply `FIRE` without purging the window state.
     
    -<span class="label label-danger">Attention</span> When purging, only the
contents of the window are cleared. The window itself is not removed and accepts new elements.
    +<span class="label label-danger">Attention</span> Purging will simply remove
the contents of the window and will leave any eventual meta-information about the window and
any trigger state intact.
    --- End diff --
    
    "eventual" -> "potential"?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message