[
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)
