You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "Marko A. Rodriguez (JIRA)" <ji...@apache.org> on 2016/03/04 19:22:40 UTC

[jira] [Closed] (TINKERPOP-1193) Add a LocalBarrier interface.

     [ https://issues.apache.org/jira/browse/TINKERPOP-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marko A. Rodriguez closed TINKERPOP-1193.
-----------------------------------------
    Resolution: Implemented
      Assignee: Marko A. Rodriguez

> Add a LocalBarrier interface.
> -----------------------------
>
>                 Key: TINKERPOP-1193
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1193
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.1.1-incubating
>            Reporter: Marko A. Rodriguez
>            Assignee: Marko A. Rodriguez
>             Fix For: 3.2.0-incubating
>
>
> Steps like {{NoOpCollectingBarrier}} and {{AggregateStep}} are {{Barrier}}-steps, but they do not need to reduce their results down to a single machine in OLAP. In fact, it is wildly expensive to do so. We should have a {{LocalBarrier}} interface which allows such steps to "barrier" but not reduce. What happens is the Steps will hold the data on the workers, merge "nothing" to master. Then master will respawn "nothing" back to the workers and the steps continue their execution. In this way, we know the barriers maintain their synchronization, but there is not unnecessary data shuffling around the cluster.
> *** Note that {{SupplyBarrierStep}} is analogous to this where its "nothing" reduction is simply a single boolean that gets and'd but means nothing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)