[jira] [Closed] (TINKERPOP-2475) Barrier step touches one more element of next loop

["Stephen Mallette (Jira)" <ji...@apache.org>]

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

Stephen Mallette closed TINKERPOP-2475.
---------------------------------------
    Fix Version/s: 3.4.9
                   3.5.0
         Assignee: Stephen Mallette
       Resolution: Fixed

> Barrier step touches one more element of next loop
> --------------------------------------------------
>
>                 Key: TINKERPOP-2475
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-2475
>             Project: TinkerPop
>          Issue Type: Bug
>          Components: process
>    Affects Versions: 3.4.8
>            Reporter: Liu-Delin
>            Assignee: Stephen Mallette
>            Priority: Major
>             Fix For: 3.5.0, 3.4.9
>
>
> This bug will preload one more element in barrier action. For example, if we have 4 vertices, and we have a barrier(2) step, we expect to get the first 2 in a barrier then the last 2 in another barrier loop. But when we get the first 2 vertices, the third one has already been loaded.
> The root cause is below code: 
> {code:java}
> @Override
> public void processAllStarts() {
>     while (this.starts.hasNext() && (this.maxBarrierSize == Integer.MAX_VALUE || this.barrier.size() < this.maxBarrierSize)) {
>         final Traverser.Admin<S> traverser = this.starts.next();
>         traverser.setStepId(this.getNextStep().getId()); // when barrier is reloaded, the traversers should be at the next step
>         this.barrier.add(traverser);
>     }
> }
> {code}
> In while loop, we use this.starts.hasNext() at first, and it will cause the vertex loading action. It will affect the performance when the vertex is saved in DB instead of memory.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)