[
https://issues.apache.org/jira/browse/TINKERPOP-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370018#comment-15370018
]
ASF GitHub Bot commented on TINKERPOP-1254:
-------------------------------------------
Github user twilmes commented on the issue:
https://github.com/apache/tinkerpop/pull/358
That's excellent! Integration tests almost ran all the way through for me,
got an odd failure during the Archetype - Server, noted below. I'm going to
rerun anyway with the latest commit and using docker this time.
```
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Apache TinkerPop ................................... SUCCESS [
9.540 s]
[INFO] Apache TinkerPop :: Gremlin Shaded ................. SUCCESS [
3.640 s]
[INFO] Apache TinkerPop :: Gremlin Core ................... SUCCESS [01:27
min]
[INFO] Apache TinkerPop :: Gremlin Test ................... SUCCESS [
11.518 s]
[INFO] Apache TinkerPop :: Gremlin Groovy ................. SUCCESS [
49.133 s]
[INFO] Apache TinkerPop :: Gremlin Groovy Test ............ SUCCESS [
8.280 s]
[INFO] Apache TinkerPop :: TinkerGraph Gremlin ............ SUCCESS [03:40
min]
[INFO] Apache TinkerPop :: Gremlin Benchmark .............. SUCCESS [
4.660 s]
[INFO] Apache TinkerPop :: Hadoop Gremlin ................. SUCCESS [06:14
min]
[INFO] Apache TinkerPop :: Spark Gremlin .................. SUCCESS [19:37
min]
[INFO] Apache TinkerPop :: Giraph Gremlin ................. SUCCESS [
02:54 h]
[INFO] Apache TinkerPop :: Neo4j Gremlin .................. SUCCESS [
4.160 s]
[INFO] Apache TinkerPop :: Gremlin Driver ................. SUCCESS [
11.340 s]
[INFO] Apache TinkerPop :: Gremlin Server ................. SUCCESS [12:58
min]
[INFO] Apache TinkerPop :: Gremlin Console ................ SUCCESS [01:36
min]
[INFO] Apache TinkerPop :: Gremlin Archetype .............. SUCCESS [
0.151 s]
[INFO] Apache TinkerPop :: Archetype - TinkerGraph ........ FAILURE [
0.374 s]
[INFO] Apache TinkerPop :: Archetype - Server ............. SKIPPED
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 03:41 h
[INFO] Finished at: 2016-07-10T15:06:49-05:00
[INFO] Final Memory: 66M/727M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on
project gremlin-archetype-tinkergraph: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: There was an
error in the forke
d process
[ERROR] java.lang.NoClassDefFoundError:
projects/standard/project/gremlin-archetype-tinkergraph/target/test-classes/com/test/example/AppTest
(wrong name: com/test/example/AppTest)
[ERROR] at java.lang.ClassLoader.defineClass1(Native Method)
[ERROR] at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
[ERROR] at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
```
> Support dropping traverser path information when it is no longer needed.
> ------------------------------------------------------------------------
>
> Key: TINKERPOP-1254
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1254
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.1.1-incubating
> Reporter: Marko A. Rodriguez
> Assignee: Ted Wilmes
>
> The most expensive traversals (especially in OLAP) are those that can not be
> "bulked." There are various reasons why two traversers at the same object can
> not be bulked, but the primary reason is {{PATH}} or {{LABELED_PATH}}. That
> is, when the history of the traverser is required, the probability of two
> traversers having the same history is low.
> A key to making traversals more efficient is to do as a much as possible to
> remove historic information from a traverser so it can get bulked. How does
> one do this?
> {code}
> g.V.as('a').out().as('b').out().where(neq('a').and().neq('b')).both().name
> {code}
> The {{LABELED_PATH}} of "a" and "b" are required up to the {{where()}} and at
> which point, at {{both()}}, they are no longer required. It would be smart to
> support:
> {code}
> traverser.dropLabels(Set<String>)
> traverser.dropPath()
> {code}
> We would then, via a {{TraversalOptimizationStrategy}} insert a step between
> {{where()}} and {{both()}} called {{PathPruneStep}} which would be a
> {{SideEffectStep}}. The strategy would know which labels were no longer
> needed (via forward lookahead) and then do:
> {code}
> public class PathPruneStep {
> final Set<String> dropLabels = ...
> final boolean dropPath = ...
> public void sideEffect(final Traverser<S> traverser) {
> final Traverser<S> start = this.starts.next();
> if(this.dropPath) start.dropPath();
> else start.dropLabels(labels);
> }
> }
> {code}
> Again, the more we can prune historic path data no longer needed, the higher
> the probability of bulking. Think about this in terms of {{match()}}.
> {code}
> g.V().match(
> a.out.b,
> b.out.c,
> c.neq.a,
> c.out.b,
> ).select("a")
> {code}
> All we need is "a" at the end. Thus, once a pattern has been passed and no
> future patterns require that label, drop it!
> This idea is related to TINKERPOP-331, but I don't think we should deal with
> manipulating the species. Thus, I think 331 is too "low level."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
