Skip to content

Conversation

@tgroh
Copy link
Member

@tgroh tgroh commented Apr 29, 2016

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

  • Make sure the PR title is formatted like:
    [BEAM-<Jira issue #>] Description of pull request
  • Make sure tests pass via mvn clean verify. (Even better, enable
    Travis-CI on your fork and ensure the whole test matrix passes).
  • Replace <Jira issue #> in the title with the actual Jira issue
    number, if there is one.
  • If this contribution is large, please file an Apache
    Individual Contributor License Agreement.

Adding additional pending elements/timers (and thus holds) always comes
before removing existing holds, so the watermark is never observed under
more stringent restrictions than currently exist.

@tgroh
Copy link
Member Author

tgroh commented Apr 29, 2016

R: @bjchambers

@bjchambers
Copy link
Contributor

The description is a bit unclear -- please update. Also, this should probably have a test to verify proper behavior.

@tgroh tgroh force-pushed the ippr_wm_pending_sequence branch from 1340e82 to 722331f Compare April 29, 2016 01:44
@tgroh
Copy link
Member Author

tgroh commented Apr 29, 2016

Fixed description, added comment.

The test is pretty complex, and I'm going to replace the update implementation with one that has a dedicated thread, and only on #extractFiredTimers; which will cause the test to no longer be particularly relevant.

@tgroh tgroh force-pushed the ippr_wm_pending_sequence branch 2 times, most recently from 97c0525 to b6d993a Compare April 29, 2016 02:34
Because the WatermarkManager is not synchronized within the call to
updatePending, the sequence in which pending queues are updated must be
in such a manner as to add additional restrictions, then remove any
restrictions which no longer apply. This ensures any intermediate read
will see at worst a more restricted watermark than the actual watermark.
@tgroh tgroh force-pushed the ippr_wm_pending_sequence branch from b6d993a to 76d3288 Compare May 2, 2016 16:42
@asfgit asfgit closed this in 659cf2e May 2, 2016
iemejia pushed a commit to iemejia/beam that referenced this pull request Jan 12, 2018
mareksimunek added a commit to mareksimunek/beam that referenced this pull request May 9, 2018
…ashJoin

[euphoria-flink] apache#260 Flink - broadcast hash join
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants