You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "Stephen Mallette (Jira)" <ji...@apache.org> on 2021/01/15 12:30:01 UTC

[jira] [Reopened] (TINKERPOP-2490) RangeGlobalStep touches next traverser when high limit is already hit

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

Stephen Mallette reopened TINKERPOP-2490:
-----------------------------------------

While running integration tests for our likely release next week, I've noticed that {{EarlyLimitStrategy} related tests are failing in a {{GraphComputer}} context.

{code}
[ERROR] Tests run: 797, Failures: 0, Errors: 1, Skipped: 7, Time elapsed: 14.266 s <<< FAILURE! - in org.apache.tinkerpop.gremlin.tinkergraph.process.TinkerGraphNoStrategyProcessStandardIntegrateTest
[ERROR] org.apache.tinkerpop.gremlin.process.traversal.strategy.optimization.EarlyLimitStrategyProcessTest  Time elapsed: 0.049 s  <<< ERROR!
java.lang.NullPointerException
{code}

It's probably not a big deal to fix, but rather than risk the change in this short time frame to release, I think it better to take our time fixing this and introducing it in 3.4.11 (I also don't have any time to focus on digging into this between now and release). 

> RangeGlobalStep touches next traverser when high limit is already hit
> ---------------------------------------------------------------------
>
>                 Key: TINKERPOP-2490
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-2490
>             Project: TinkerPop
>          Issue Type: Bug
>          Components: process
>    Affects Versions: 3.4.8
>            Reporter: Guo Junshi
>            Assignee: Stephen Mallette
>            Priority: Major
>             Fix For: 3.5.0, 3.4.10
>
>
> In FilterStep, the processNextStart() method will first retrieve next traverser and then apply filtering logic. But for RangleGlobalStep, if high limit is already hit, there will be no need to get next traverser.
> {code:java}
> @Override
> protected Traverser.Admin<S> processNextStart() {
>     while (true) {
>         final Traverser.Admin<S> traverser = this.starts.next();
>         if (this.filter(traverser))
>             return traverser;
>     }
> }
> {code}
> An example would be limit step: g.V().limit(1). This query will touch 2 vertices although only 1 vertex will be returned.
> This extra data loading will cause performance defects if DB data loading is involved. It is not a functionality bug, but for better performance, we'd better check high range limit first before touching next traversal.



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