[jira] [Closed] (TINKERPOP3-961) Barrier steps need to truly "barrier" in OLAP.

["Marko A. Rodriguez (JIRA)" <ji...@apache.org>]

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

Marko A. Rodriguez closed TINKERPOP3-961.
-----------------------------------------
    Resolution: Duplicate

Doh. Already write this up in TINKERPOP3-951

> Barrier steps need to truly "barrier" in OLAP.
> ----------------------------------------------
>
>                 Key: TINKERPOP3-961
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-961
>             Project: TinkerPop 3
>          Issue Type: Bug
>          Components: process
>    Affects Versions: 3.1.0-incubating
>            Reporter: Marko A. Rodriguez
>            Assignee: Marko A. Rodriguez
>
> A {{Barrier}} step works great in OLTP. It blocks until it can not longer pull from the previous step. At which point, it drains its barrier to the right step.
> Unfortunately, in OLAP which is a barrier system (BSP), the semantics are not correct. For {{ReducingBarrierSteps}}, these MUST be the final step in the traversal. However, for {{CollectingBarrierSteps}} (e.g. {{aggregate()}}, {{barrier()}}), the semantics are messed up. Given that OLAP works in a lock step fashion, a {{barrier()}} will pull from the left step and will be "ready to drain" at the end of that iteration as there is nothing left to pull. Thus, while more traversers my come in the previous step, the {{barrier()}} has already drained what it has gathered to subsequent step. Thus, its a "local barrier" and not a "global barrier."
> This problem is most apparent when using sacks and merging at an iteration doesn't work. I will provide an explicit example over {{MODERN}} later. Finally, note that this might be a way to also solve the "allow mid-traversal barriers" problem where {{SumStep}} could be mid-traversal (i.e. {{ReducingBarrierSteps}}).



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