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

Liu-Delin updated TINKERPOP-2475:
---------------------------------
    Description: 
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.

 

  was:
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.

 


> 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
>            Priority: Major
>
> 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)

Reply via email to