[
https://issues.apache.org/jira/browse/TINKERPOP-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette closed TINKERPOP-3100.
---------------------------------------
Fix Version/s: 4.0.0
3.7.4
3.8.0
Assignee: Stephen Mallette
Resolution: Fixed
> Traversal.Admin.lock() has excessive recursion
> ----------------------------------------------
>
> Key: TINKERPOP-3100
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3100
> Project: TinkerPop
> Issue Type: Bug
> Components: console, process
> Affects Versions: 3.7.2
> Environment: M1 Macbook, 16GB RAM
> Reporter: Cameron Fiander
> Assignee: Stephen Mallette
> Priority: Critical
> Labels: performance
> Fix For: 4.0.0, 3.7.4, 3.8.0
>
>
> Hi, we are currently upgrading to TinkerPop 3.7, and noticed that some of our
> larger queries were taking much longer than expected to applyStrategies /
> lock.[ I've created an example project with a contrived complex traversal
> that reproduces the
> issue|https://github.com/camfiander-sonrai/TinkerPopLockPerformanceRepro].
> I noticed that many of the children steps were getting locked more than once,
> which shouldn't be necessary. I think the problem is
> [here|https://github.com/apache/tinkerpop/blob/3.7.2/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/DefaultTraversal.java#L333].
> {{{}applyTraversalRecursively{}}}, called from the traversal root, should
> apply the {{lock()}} to all children, grandchildren, and so on. But each
> child also calls {{{}applyTraversalRecursively{}}}, meaning the number of
> times a step is locked scales with the depth of the traversal.
> {code:java}
> # TinkerPop 3.5.3
> Applied strategies in PT3.695S
> # TinkerPop 3.7.2
> Applied strategies in PT15.079S{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
