beam-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (BEAM-97) Input watermarks can never be null
Date Mon, 07 Mar 2016 18:13:40 GMT


ASF GitHub Bot commented on BEAM-97:

GitHub user mshields822 opened a pull request:

    [BEAM-97] Input watermarks can never be null


You can merge this pull request into a Git repository by running:

    $ git pull non-null-output-watermark

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #30
commit f27b0f8f836d2c6df7de27310444b011ef8eb6f8
Author: Mark Shields <>
Date:   2016-03-03T04:45:59Z

    Basic non-null checks

commit a72bc78adf6ed2fcd8e0440d02c474d939e7033b
Author: Mark Shields <>
Date:   2016-03-04T23:16:33Z

    Input watermarks can never be null.

commit 4120e94aa3a057835035f9a4939f707347bc5c13
Author: Mark Shields <>
Date:   2016-03-05T17:40:10Z

    No .* imports.

commit 42923ef6fc7842352df2c297f3664bc377b6c8ac
Author: Mark Shields <>
Date:   2016-03-07T18:09:41Z

    Fix broken build


> Input watermarks can never be null
> ----------------------------------
>                 Key: BEAM-97
>                 URL:
>             Project: Beam
>          Issue Type: Bug
>          Components: sdk-java-core
>            Reporter: Mark Shields
>            Assignee: Mark Shields
> A null input watermark (eg the result of TimerInternals.currentInputWatermarkTime())
is currently interpreted to mean 'computation is still starting and watermark is not yet known'.
However, the Google runner was also returning null for 'computation has just restarted and
previous watermark has not been established'. As a result code such as WatermarkHold would
create data holds using the first interpretation which is unsound for the second interpretation.
> Instead, input watermarks should never be null so the interpretation is never ambiguous.
The Google runner is ready to support this.

This message was sent by Atlassian JIRA

View raw message