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-2899) Universal Local Runner
Date Mon, 20 Nov 2017 19:06:00 GMT


ASF GitHub Bot commented on BEAM-2899:

GitHub user tgroh opened a pull request:

    [BEAM-2899] Decompose Direct Execution Components

    Follow this checklist to help us incorporate your contribution quickly and easily:
     - [ ] Make sure there is a [JIRA issue](
filed for the change (usually before you start working on it).  Trivial changes like typos
do not require a JIRA issue.  Your pull request should address just this issue, without pulling
in other changes.
     - [ ] Each commit in the pull request should have a meaningful subject line and body.
     - [ ] Format the pull request title like `[BEAM-XXX] Fixes bug in ApproximateQuantiles`,
where you replace `BEAM-XXX` with the appropriate JIRA issue.
     - [ ] Write a pull request description that is detailed enough to understand what the
pull request does, how, and why.
     - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will
be performed on your pull request automatically.
     - [ ] If this contribution is large, please file an Apache [Individual Contributor License
    Specifically, this encapsulates Bundle Execution and Outstanding Work Management
    into separate concepts. This enables other implementations to be provided to perform
    the physical execution without the scheduling logic also being present.

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

    $ git pull bundle_executor

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 #4151
commit e01357c4e345b2f7c9db40957bb38b45dc35403b
Author: Thomas Groh <>
Date:   2017-11-15T18:59:44Z

    Add an interface to execute Bundles
    Use a reference to the Bundle Executor explicitly in the Monitor, which
    is responsible for scheduling work.
    Eventually, the Montior Runnable will be configurable within an
    executor, which requires it to interact wiht the actual executor through
    meaningful interfaces.

commit 7e62be5cc2feaf1bf5f012c78b29377a0d2bb3df
Author: Thomas Groh <>
Date:   2017-11-15T21:22:53Z

    Move outstanding work maintenance out of evaluateBundle
    This is used to determine if the monitor should add more work. It should
    belong to the monitor and its collaborators to determine the amount of
    work it has scheduled and completed, not the component which is
    responsible for physically executing the work.

commit 49c15cec49f931b4fc9604617439c316272f5eb9
Author: Thomas Groh <>
Date:   2017-11-16T01:07:11Z

    Add an ExecutionDriver to local java
    This is responsible for actually driving work progress. This contains
    the responsibilities for determining what work will be scheduled and
    when, with no conception of any of how the underlying work is executed.

commit ddf81fd4d612bfd682a2bdd816dbcacea658a874
Author: Thomas Groh <>
Date:   2017-11-20T19:02:12Z

    Migrate MonitorRunnable into QuiescenceDriver
    This encapsulates the logic implementing quiescence into a single
    component, which is decoupled from the underlying bundle and pipeline
    execution mechanisms.


> Universal Local Runner
> ----------------------
>                 Key: BEAM-2899
>                 URL:
>             Project: Beam
>          Issue Type: Improvement
>          Components: runner-core
>            Reporter: Henning Rohde
>            Assignee: Thomas Groh
>              Labels: portability
> To make the portability effort tractable, we should implement a Universal Local Runner
(ULR) in Java that runs in a single server process plus docker containers for the SDK harness
containers. It would serve multiple purposes:
>   (1) A reference implementation for other runners. Ideally, any new feature should be
implemented in the ULR first.
>   (2) A fully-featured test runner for SDKs who participate in the portability framework.
It thus complements the direct runners.
>   (3) A test runner for user code that depends on or customizes the runtime environment.
For example, a DoFn that shells out has a dependency that may be satisfied on the user's desktop
(and thus works fine on the direct runner), but perhaps not by the container harness image.
The ULR allows for an easy way to find out.
> The Java direct runner presumably has lots of pieces that can be reused.

This message was sent by Atlassian JIRA

View raw message