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-367) GetFractionConsumed() inaccurate for non-uniform records
Date Wed, 22 Jun 2016 00:29:58 GMT


ASF GitHub Bot commented on BEAM-367:

GitHub user ianzhou1 opened a pull request:

    [BEAM-367] Modify offset range tracker to use first response as start offset

    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](

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

    $ git pull OffsetRangeTrackerUpdateStartOffset

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 #515
commit d9f11ad88d428feefba50faa8f64b1912da97362
Author: Ian Zhou <>
Date:   2016-06-22T00:23:09Z

    Modify offset range tracker to use first response as start offset


> GetFractionConsumed() inaccurate for non-uniform records
> --------------------------------------------------------
>                 Key: BEAM-367
>                 URL:
>             Project: Beam
>          Issue Type: Improvement
>          Components: sdk-java-gcp
>            Reporter: Ian Zhou
>            Assignee: Daniel Halperin
>            Priority: Minor
> GetFractionConsumed() provides inaccurate progress updates for clustered records. For
example, for a range spanning [1, 10], a cluster of records around 5 (e.g. 5.000001 ..., 5.000009)
will be recorded as ~50% complete upon reading the first record, and will remain at this percentage
until the final record has been read. Instead, the start of the range should be changed to
the first record seen (e.g. new range [5.000001, 10]). The end of the range can be changed
over time through dynamic work rebalancing.

This message was sent by Atlassian JIRA

View raw message