[jira] [Commented] (TINKERPOP-1397) StarVertex self edge has buggy interaction with graph filters

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15418700#comment-15418700
 ] 

ASF GitHub Bot commented on TINKERPOP-1397:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/377
  
VOTE +1


> StarVertex self edge has buggy interaction with graph filters
> -
>
> Key: TINKERPOP-1397
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1397
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.1.3
>Reporter: Dan LaRocque
> Fix For: 3.1.4
>
>
> When StarVertex adds a self-loop, it adds an instance of concrete type 
> {{StarOutEdge}} to both its {{outEdges}} map and its {{inEdges}} map.
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L321-L330
> (line 329 adds a {{StarOutEdge}} to the {{inEdges}} map)
> Having a {{StarOutEdge}} in the {{inEdges}} map mostly doesn't matter.  
> However, this does matter in the {{applyGraphFilter}} method.  This method 
> uses {{instanceof StarOutEdge}} to guess whether an edge's original direction 
> was in or out:
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L470
> If you trace {{applyGraphFilter}} through, you see that a {{StarVertex}} with 
> a self-loop can pop out of {{applyGraphFilter}} with two out edges 
> corresponding to the self loop and no in edges.  This leads to weird 
> traversal results.  One way to trigger this is to write a 
> {{GraphFilterAware}} {{InputRDD}} that produces {{StarVertex}} instances and 
> then run a {{g.V()inE("somelabel")}}, so that TP pushes down the 
> "somelabel" constraint, which is how I got here.
> I think {{addEdge}} should continue putting a {{StarOutEdge}} into 
> {{outEdges}}, like it already does.  -However, it should put a {{StarInEdge}} 
> into {{inEdges}}.  This would increase the object overhead associated with 
> StarVertices that have self loops (two edge objs instead of one).  If we 
> wanted to be obsessive about optimizing this case we could probably pervert 
> the {{inEdge}}/{{outEdge}} datastructure contents to do it, but IMHO that's 
> not worth it.-  Actually, I'm no longer convinced that's safe, since I think 
> it would alter some of StarVertex's other semantics.  For one, I think 
> retrieving an edge and setting a property on it would probably break.
> I'll make a PR soon.
> I don't know all of the versions this affects, but I do know it affects 3.2.1.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1397) StarVertex self edge has buggy interaction with graph filters

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15416240#comment-15416240
 ] 

ASF GitHub Bot commented on TINKERPOP-1397:
---

GitHub user dalaro opened a pull request:

https://github.com/apache/tinkerpop/pull/378

TINKERPOP-1397 Fix StarGraph.addEdge

See:

* old PR #372
* JIRA issue https://issues.apache.org/jira/browse/TINKERPOP-1397

As far as I can tell, GraphFilter did not exist in 3.1, and it may not even 
be possible to induce the buggy traversal behavior describe in #372 (which was 
all based on master / 3.2).  The underlying datastructure corruption -- putting 
a StarOutEdge into the `inEdges` map -- does exist on 3.1, and @okram's 
`addEdge` fix applies cleanly on 3.1, but without `applyGraphFilter`, I'm not 
sure it even matters for correctness on 3.1.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dalaro/incubator-tinkerpop TINKERPOP-1397-tp31

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/378.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #378


commit 0022b7f6be25eb7d3c778b137beb6e8a7d2784ca
Author: Dan LaRocque 
Date:   2016-08-10T22:52:13Z

TINKERPOP-1397 Fix StarGraph.addEdge

For self-loops, StarGraph.addEdge used to put a single StarOutEdge
into both its inEdges and outEdges maps, potentially causing problems
in applyGraphFilter.

This change makes StarGraph.addEdge put the appropriate type of edge
(Star(Out/In)Edge) in the associated map.  The IDs for each edge
instance are kept in agreement.

This change is @okram's, who suggested it in PR #372.  I merely
reviewed it and added a couple of comments.




> StarVertex self edge has buggy interaction with graph filters
> -
>
> Key: TINKERPOP-1397
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1397
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.1.3
>Reporter: Dan LaRocque
> Fix For: 3.1.4
>
>
> When StarVertex adds a self-loop, it adds an instance of concrete type 
> {{StarOutEdge}} to both its {{outEdges}} map and its {{inEdges}} map.
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L321-L330
> (line 329 adds a {{StarOutEdge}} to the {{inEdges}} map)
> Having a {{StarOutEdge}} in the {{inEdges}} map mostly doesn't matter.  
> However, this does matter in the {{applyGraphFilter}} method.  This method 
> uses {{instanceof StarOutEdge}} to guess whether an edge's original direction 
> was in or out:
> https://github.com/apache/tinkerpop/blob/8f7218d53a31cf41f4a0269d64ac1c27dfc0907a/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/star/StarGraph.java#L470
> If you trace {{applyGraphFilter}} through, you see that a {{StarVertex}} with 
> a self-loop can pop out of {{applyGraphFilter}} with two out edges 
> corresponding to the self loop and no in edges.  This leads to weird 
> traversal results.  One way to trigger this is to write a 
> {{GraphFilterAware}} {{InputRDD}} that produces {{StarVertex}} instances and 
> then run a {{g.V()inE("somelabel")}}, so that TP pushes down the 
> "somelabel" constraint, which is how I got here.
> I think {{addEdge}} should continue putting a {{StarOutEdge}} into 
> {{outEdges}}, like it already does.  -However, it should put a {{StarInEdge}} 
> into {{inEdges}}.  This would increase the object overhead associated with 
> StarVertices that have self loops (two edge objs instead of one).  If we 
> wanted to be obsessive about optimizing this case we could probably pervert 
> the {{inEdge}}/{{outEdge}} datastructure contents to do it, but IMHO that's 
> not worth it.-  Actually, I'm no longer convinced that's safe, since I think 
> it would alter some of StarVertex's other semantics.  For one, I think 
> retrieving an edge and setting a property on it would probably break.
> I'll make a PR soon.
> I don't know all of the versions this affects, but I do know it affects 3.2.1.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15375441#comment-15375441
 ] 

ASF GitHub Bot commented on TINKERPOP-1278:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/359


> Implement Gremlin-Python and general purpose language variant test 
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language 
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model 
> presented in 
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
>  Moreover, on every {{mvn clean install}}, the code for these variants is 
> generated.
> Given the desire to separate language variants from language drivers, I think 
> that a language driver for each variant above should be "plugable." Moreover, 
> we should provide one driver implementation for each -- simple GremlinServer 
> REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
>   gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
>   gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we 
> have to implement each {{g_V_out_repeatXasXaXX}} test case in 
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to 
> convert all those tests from Gremlin-Java to the respective host language? 
> However, even if we do that, we still have the problem of how to test the 
> returned results. 
> I think what we should test the returned results using the JVM. For instance, 
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a 
> massive headache. All we have to do is create a {{GraphProvider}} that uses 
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around 
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the 
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb   // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15372807#comment-15372807
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
Adding my email on dev@ to here.

I’m not following this PR too closely so what I might be saying is a 
already known/argued against/etc.

1. I think we should go with @robertdale proposal of int32, int64, 
Vertex, uuid, etc. instead of Java class names.
2. In Java we then have a `Map` for typecasting 
accordingly.
3. This would make GraphSON 2.0 perfect for Bytecode serialization in 
TINKERPOP-1278.
4. I think that if a Vertex, Edge, etc. doesn’t have properties, outV, 
etc. then don’t even have those fields in the representation.
5. Most of the serialization back and forth will be `ReferenceXXX` 
elements and thus, don’t create more Maps/lists for no reason. — less chars.

For me, my interests with this work is all about a language agnostic way of 
sending Gremlin traversal bytecode between different languages. This work is 
exactly what I am looking for.


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1379) unaccounted excess in TailGlobalStep

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15386177#comment-15386177
 ] 

ASF GitHub Bot commented on TINKERPOP-1379:
---

GitHub user pluradj opened a pull request:

https://github.com/apache/tinkerpop/pull/363

TINKERPOP-1379 remove excess bulk in tail buffer

https://issues.apache.org/jira/browse/TINKERPOP-1379

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1379

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/363.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #363


commit d43db2bb2f3f4988503f0cdedbd1877cd542c502
Author: Jason Plurad 
Date:   2016-07-20T16:31:53Z

remove excess bulk in tail buffer




> unaccounted excess in TailGlobalStep
> 
>
> Key: TINKERPOP-1379
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1379
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Jason Plurad
>
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/TailGlobalStep.java#L71-L74
> This code doesn't account for the excess removed from {{tailBulk}}. This can 
> cause the code to set incorrect bulk values when there are multiple 
> traversers in the tail buffer.
> I observed this behavior intermittently in TitanGraph 
> (https://github.com/thinkaurelius/titan/pull/1312), which doesn't allow user 
> defined ids, so the ordering of the traversers in the TraverserSet is a lot 
> more random than the unit tests using TinkerGraph.
> This issue is reproducible with TinkerGraph (master/3.2.1). Instead of 
> loading from one of the data files, manually create the graph with the ids in 
> inverted order.
> {noformat}
> graph = TinkerGraph.open();
> // graph.io(IoCore.gryo()).readGraph("tinkerpop-modern.kryo");
> final Vertex v1 = graph.addVertex(T.id, 6L, T.label, "person", "name", 
> "marko", "age", 29);
> final Vertex v2 = graph.addVertex(T.id, 5L, T.label, "person", "name", 
> "vadas", "age", 27);
> final Vertex v3 = graph.addVertex(T.id, 4L, T.label, "software", "name", 
> "lop", "lang", "java");
> final Vertex v4 = graph.addVertex(T.id, 3L, T.label, "person", "name", 
> "josh", "age", 32);
> final Vertex v5 = graph.addVertex(T.id, 2L, T.label, "software", "name", 
> "ripple", "lang", "java");
> final Vertex v6 = graph.addVertex(T.id, 1L, T.label, "person", "name", 
> "peter", "age", 35);
> v1.addEdge("knows", v2, "weight", 0.5d);
> v1.addEdge("knows", v4, "weight", 1.0d);
> v1.addEdge("created", v2, "weight", 0.4d);
> v4.addEdge("knows", v5, "weight", 1.0d);
> v4.addEdge("knows", v3, "weight", 0.4d);
> v6.addEdge("knows", v3, "weight", 0.2d);
> if (graph.features().graph().supportsTransactions()) graph.tx().commit();
> final GraphTraversalSource g = graph.traversal();
> String result = 
> g.V().repeat(both()).times(3).tail(7).count().next().toString();
> boolean success = "7".equals(result);
> {noformat}
> The fix is this:
> {noformat}
> if (excess > 0) {
> oldest.setBulk(oldestBulk-excess);
> // Account for the loss of excess in the tail buffer
> this.tailBulk -= excess;
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1360) intermittent error in spark-gremlin integration test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371720#comment-15371720
 ] 

ASF GitHub Bot commented on TINKERPOP-1360:
---

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/361
  
Java is brain damaged when comparing numbers. Don't blame JSON.


> intermittent error in spark-gremlin integration test
> 
>
> Key: TINKERPOP-1360
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1360
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
>
> This error intermittently comes up during the Spark integration tests
> {noformat}
> Tests run: 457, Failures: 1, Errors: 0, Skipped: 150, Time elapsed: 110.068 
> sec <<< FAILURE! - in 
> org.apache.tinkerpop.gremlin.spark.process.computer.SparkGraphComputerProcessIntegrateTest
> g_V_hasXageX_propertiesXnameX(org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesTest$Traversals)
>   Time elapsed: 0.185 sec  <<< FAILURE!
> java.lang.AssertionError: expected: java.lang.Integer<6> but was: 
> java.lang.Long<6>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesTest.g_V_hasXageX_propertiesXnameX(PropertiesTest.java:103)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at 
> org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:53)
>   at 
> org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:37)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:212)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> Reproduce steps:
> {noformat}
> mvn verify -q -DskipIntegrationTests=false -pl spark-gremlin
> {noformat}
> Environments used:
> {noformat}
> Apache Maven 3.0.5
> Maven home: /usr/share/maven
> Java version: 

[jira] [Commented] (TINKERPOP-1360) intermittent error in spark-gremlin integration test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15372049#comment-15372049
 ] 

ASF GitHub Bot commented on TINKERPOP-1360:
---

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/361
  
VOTE: +1


> intermittent error in spark-gremlin integration test
> 
>
> Key: TINKERPOP-1360
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1360
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
>
> This error intermittently comes up during the Spark integration tests
> {noformat}
> Tests run: 457, Failures: 1, Errors: 0, Skipped: 150, Time elapsed: 110.068 
> sec <<< FAILURE! - in 
> org.apache.tinkerpop.gremlin.spark.process.computer.SparkGraphComputerProcessIntegrateTest
> g_V_hasXageX_propertiesXnameX(org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesTest$Traversals)
>   Time elapsed: 0.185 sec  <<< FAILURE!
> java.lang.AssertionError: expected: java.lang.Integer<6> but was: 
> java.lang.Long<6>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesTest.g_V_hasXageX_propertiesXnameX(PropertiesTest.java:103)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at 
> org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:53)
>   at 
> org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:37)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:212)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> Reproduce steps:
> {noformat}
> mvn verify -q -DskipIntegrationTests=false -pl spark-gremlin
> {noformat}
> Environments used:
> {noformat}
> Apache Maven 3.0.5
> Maven home: /usr/share/maven
> Java version: 1.8.0_91, vendor: Oracle Corporation
> Java home: 

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15372071#comment-15372071
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user PommeVerte commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
ok I caught up and checked code. I think what @robertdale suggests on the 
typing end would be really nice (`int64`, `int32`, etc). But we can keep that 
for the thread stephen linked to.

I VOTE +1 on this. @spmallette if you could just add a mention in the 
documentation that the basic types are based off of the JVM types that would be 
a nice bonus to have. 

Nice work @newkek, some nice effort went into this.  


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1071) Enhance pre-processor output

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15353231#comment-15353231
 ] 

ASF GitHub Bot commented on TINKERPOP-1071:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/348
  
VOTE +1


> Enhance pre-processor output
> 
>
> Key: TINKERPOP-1071
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1071
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.0.2-incubating
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> If the pre-processor recognizes an error, it will currently just cancel the 
> process and remove the partially processed file. That makes it hard to figure 
> out why it actually failed. Would be nice if the pre-processor would show the 
> last 10 lines of the partially processed file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1071) Enhance pre-processor output

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15353314#comment-15353314
 ] 

ASF GitHub Bot commented on TINKERPOP-1071:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/348


> Enhance pre-processor output
> 
>
> Key: TINKERPOP-1071
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1071
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.0.2-incubating
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> If the pre-processor recognizes an error, it will currently just cancel the 
> process and remove the partially processed file. That makes it hard to figure 
> out why it actually failed. Would be nice if the pre-processor would show the 
> last 10 lines of the partially processed file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1349) RepeatUnrollStrategy should unroll loops while maintaining equivalent semantics.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15353703#comment-15353703
 ] 

ASF GitHub Bot commented on TINKERPOP-1349:
---

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/349
  
VOTE: +1


> RepeatUnrollStrategy should unroll loops while maintaining equivalent 
> semantics.
> 
>
> Key: TINKERPOP-1349
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1349
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.0-incubating
>
>
> Create {{RepeatUnrollStrategy}} that will unroll patterns such as:
> {code}
> repeat(out()).times(3)
> // ->
> out().barrier().out().barrier().out().barrier()
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1071) Enhance pre-processor output

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352879#comment-15352879
 ] 

ASF GitHub Bot commented on TINKERPOP-1071:
---

GitHub user dkuppitz opened a pull request:

https://github.com/apache/tinkerpop/pull/348

TINKERPOP-1071 Enhance pre-processor output


https://issues.apache.org/jira/browse/TINKERPOP-1071

To test the changes, I've added an invalid `foo + bar` line in one of the 
code blocks. Here's how the output looked like:

```
$ bin/process-docs.sh 

==
+   Installing Plugins   +
==

 * tinkerpop-sugar ... done
 * hadoop-gremlin ... done
 * spark-gremlin ... done
 * giraph-gremlin ... done
 * neo4j-gremlin ... done



+   Processing AsciiDocs   +


 * source:   /projects/apache/tinkerpop/docs/src/reference/index.asciidoc
   target:   
/projects/apache/tinkerpop/target/postprocess-asciidoc/reference/index.asciidoc
   progress: 
[]
 100%

 * source:   /projects/apache/tinkerpop/docs/src/reference/preface.asciidoc
   target:   
/projects/apache/tinkerpop/target/postprocess-asciidoc/reference/preface.asciidoc
   progress: 
[]
 100%

 * source:   /projects/apache/tinkerpop/docs/src/reference/intro.asciidoc
   target:   
/projects/apache/tinkerpop/target/postprocess-asciidoc/reference/intro.asciidoc
   progress: 
[==>
 ] 74%No such property: foo for class: groovysh_evaluate
Display stack trace? [yN] pb(295); ''
groovysh_parse: 2: expecting an identifier, found 'this' @ line 2, column 
19.
   lities. In total, this is The TinkerPop.'
 ^

1 error
Display stack trace? [yN] pb(395); '// LAST LINE'


Last 10 lines of 
/projects/apache/tinkerpop/target/postprocess-asciidoc/reference/intro.asciidoc:

==>v[1]
gremlin> g.V(marko).out('knows')  <2>
==>v[2]
==>v[4]
gremlin> g.V(marko).out('knows').values('name')  <3>
==>vadas
==>josh
gremlin> foo + bar
gremlin> lities. In total, this is The TinkerPop.'
gremlin> 

xargs: /projects/apache/tinkerpop/docs/preprocessor/preprocess-file.sh: 
exited with status 255; aborting
```

Unfortunately I cannot separate the error message from the progress bar 
output (both go to stderr), but I think  it already helps a lot to see the last 
10 lines of the output file.

VOTE: +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1071

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/348.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #348


commit 98f09bad615c2be3b5f8a4145f9a106977f13d6b
Author: Daniel Kuppitz 
Date:   2016-06-28T12:02:32Z

Enhanced pre-processor output for failure cases.




> Enhance pre-processor output
> 
>
> Key: TINKERPOP-1071
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1071
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.0.2-incubating
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> If the pre-processor recognizes an error, it will currently just cancel the 
> process and remove the partially processed file. That makes it hard to figure 
> out why it actually failed. Would be nice if the pre-processor would show the 
> last 10 lines of the partially processed file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1355) Design HasContainer for extension

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364130#comment-15364130
 ] 

ASF GitHub Bot commented on TINKERPOP-1355:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/355
  
VOTE +1


> Design HasContainer for extension
> -
>
> Key: TINKERPOP-1355
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1355
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Bryn Cooke
>Priority: Critical
>
> Currently HasContainer is final. This means that Graph implementations cannot 
> support their own type systems across the entire traversal.
> Given the traversal:
> g.V.has('foo', nonTinkerpopType).out('bar').has('foo', nonTinkerpopType)
> Say that the initial traversal g.V.has('foo', nonTinkerpopType) is dealt with 
> via strategy, the non-Tinkerpop type can be dealt with. However the rest of 
> the traversal is processed via the default Tinkerpop pipeline, and as such it 
> doesn't know how to deal with type conversions/comparisons etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1355) Design HasContainer for extension

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364139#comment-15364139
 ] 

ASF GitHub Bot commented on TINKERPOP-1355:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/355


> Design HasContainer for extension
> -
>
> Key: TINKERPOP-1355
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1355
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Bryn Cooke
>Priority: Critical
>
> Currently HasContainer is final. This means that Graph implementations cannot 
> support their own type systems across the entire traversal.
> Given the traversal:
> g.V.has('foo', nonTinkerpopType).out('bar').has('foo', nonTinkerpopType)
> Say that the initial traversal g.V.has('foo', nonTinkerpopType) is dealt with 
> via strategy, the non-Tinkerpop type can be dealt with. However the rest of 
> the traversal is processed via the default Tinkerpop pipeline, and as such it 
> doesn't know how to deal with type conversions/comparisons etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1320) GremlinGroovyScriptEngineFileSandboxTest throws error: URI is not hierarchical

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364213#comment-15364213
 ] 

ASF GitHub Bot commented on TINKERPOP-1320:
---

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/336
  
VOTE: +1


> GremlinGroovyScriptEngineFileSandboxTest throws error: URI is not hierarchical
> --
>
> Key: TINKERPOP-1320
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1320
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> This is similar to TINKERPOP-1317. The differences here are
> * The {{TestHelper.generateTempFileFromResource()}} call to load the resource 
> is happening from the {{public static void init()}} method before a graph 
> instance is available.
> * A reference to {{GremlinGroovyScriptEngineFileSandboxTest.class}} is still 
> required to located the {{sandbox.yaml}} found in the {{gremlin-test.jar}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1350) Server locks when submitting parallel requests on session

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364261#comment-15364261
 ] 

ASF GitHub Bot commented on TINKERPOP-1350:
---

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/350
  
VOTE: +1


> Server locks when submitting parallel requests on session
> -
>
> Key: TINKERPOP-1350
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1350
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.3, 3.2.1
>
>
> This really is only a problem when there is some form of long blocking script 
> submitted and only on a session when done in parallel, like:
> {code}
> final ResultSet first = client.submit(
> "Object mon1 = 'mon1';\n" +
> "synchronized (mon1) {\n" +
> "mon1.wait();\n" +
> "} ");
> final ResultSet second = client.submit(
> "Object mon2 = 'mon2';\n" +
> "synchronized (mon2) {\n" +
> "mon2.wait();\n" +
> "}");
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1354) Include all static enum imports in request validation for bindings

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364222#comment-15364222
 ] 

ASF GitHub Bot commented on TINKERPOP-1354:
---

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/354
  
VOTE: +1


> Include all static enum imports in request validation for bindings
> --
>
> Key: TINKERPOP-1354
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1354
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>  Labels: breaking
> Fix For: 3.1.3, 3.2.1
>
>
> Gremlin Server validates the bindings of incoming requests and returns an 
> error for any reserved terms. The list of reserved terms only includes {{T}} 
> but should also include others like {{Order}} and {{Scope}} so that users 
> don't inadvertently override them with a request binding. When that happens 
> Gremlin Server throws a not so easy to understand error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1338) Bump to Groovy 2.4.7

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364310#comment-15364310
 ] 

ASF GitHub Bot commented on TINKERPOP-1338:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/356
  
Note that it's not sufficient in this case to only run gremlin server 
integration tests. You should probably run the whole suite. When i run that 
with docker via `docker/build.sh -t -i -n` i get tons of:

```text
Caused by: java.lang.IllegalArgumentException: Unable to create serializer 
"com.esotericsoftware.kryo.serializers.FieldSerializer" for class: void
at com.esotericsoftware.kryo.Kryo.newSerializer(Kryo.java:335)
at com.esotericsoftware.kryo.Kryo.newDefaultSerializer(Kryo.java:314)
at com.twitter.chill.KryoBase.newDefaultSerializer(KryoBase.scala:48)
at com.esotericsoftware.kryo.Kryo.getDefaultSerializer(Kryo.java:307)
at com.esotericsoftware.kryo.Kryo.register(Kryo.java:351)
at 
org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoRegistrator.registerClasses(GryoRegistrator.java:94)
at 
org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoRegistrator.registerClasses(GryoRegistrator.java:65)
at 
org.apache.spark.serializer.KryoSerializer$$anonfun$newKryo$6.apply(KryoSerializer.scala:124)
at 
org.apache.spark.serializer.KryoSerializer$$anonfun$newKryo$6.apply(KryoSerializer.scala:124)
at scala.Option.foreach(Option.scala:236)
at 
org.apache.spark.serializer.KryoSerializer.newKryo(KryoSerializer.scala:124)
at 
org.apache.tinkerpop.gremlin.spark.structure.io.gryo.IoRegistryAwareKryoSerializer.newKryo(IoRegistryAwareKryoSerializer.java:57)
at 
org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedKryoShimService.initialize(UnshadedKryoShimService.java:144)
at 
org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedKryoShimService.applyConfiguration(UnshadedKryoShimService.java:106)
at 
org.apache.tinkerpop.gremlin.structure.io.gryo.kryoshim.KryoShimServiceLoader.load(KryoShimServiceLoader.java:125)
at 
org.apache.tinkerpop.gremlin.spark.process.computer.SparkHadoopGraphGryoRegistratorProvider.getBaseConfiguration(SparkHadoopGraphGryoRegistratorProvider.java:48)
at 
org.apache.tinkerpop.gremlin.AbstractGraphProvider.newGraphConfiguration(AbstractGraphProvider.java:70)
at 
org.apache.tinkerpop.gremlin.GraphProvider.standardGraphConfiguration(GraphProvider.java:144)
at 
org.apache.tinkerpop.gremlin.GraphManager$ManagedGraphProvider.standardGraphConfiguration(GraphManager.java:132)
at 
org.apache.tinkerpop.gremlin.AbstractGremlinTest.setup(AbstractGremlinTest.java:81)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at 
org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:54)
at 
org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:37)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at 
org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:212)
at 
org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at 

[jira] [Commented] (TINKERPOP-1319) several FeatureRequirement annotations are incorrect in gremlin-test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364316#comment-15364316
 ] 

ASF GitHub Bot commented on TINKERPOP-1319:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/335
  
VOTE +1


> several FeatureRequirement annotations are incorrect in gremlin-test
> 
>
> Key: TINKERPOP-1319
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1319
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> Several {{@FeatureRequirement}} annotations are incorrect in these 
> {{gremlin-test}} tests
> * EdgeTest.java
> * FeatureSupportTest.java
> * GraphTest.java
> * PropertyTest.java
> * VertexPropertyTest.java
> * VertexTest.java
> I'll submit a patch for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1352) Connection Pool doesn't always grow

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15366456#comment-15366456
 ] 

ASF GitHub Bot commented on TINKERPOP-1352:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/352
  
VOTE +1


> Connection Pool doesn't always grow 
> 
>
> Key: TINKERPOP-1352
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1352
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.3, 3.2.1
>
>
> With certain configurations (that aren't terribly intuitive) of the driver, 
> the connection pool won't grow properly - this includes the default 
> configuration. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1319) several FeatureRequirement annotations are incorrect in gremlin-test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15366649#comment-15366649
 ] 

ASF GitHub Bot commented on TINKERPOP-1319:
---

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/335
  
I'll open a JIRA for that issue.


> several FeatureRequirement annotations are incorrect in gremlin-test
> 
>
> Key: TINKERPOP-1319
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1319
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> Several {{@FeatureRequirement}} annotations are incorrect in these 
> {{gremlin-test}} tests
> * EdgeTest.java
> * FeatureSupportTest.java
> * GraphTest.java
> * PropertyTest.java
> * VertexPropertyTest.java
> * VertexTest.java
> I'll submit a patch for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1319) several FeatureRequirement annotations are incorrect in gremlin-test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15366630#comment-15366630
 ] 

ASF GitHub Bot commented on TINKERPOP-1319:
---

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/335
  
Just confirmed that I can see the same problem occur intermittently on 
`tp31` without the fixes from this PR.


> several FeatureRequirement annotations are incorrect in gremlin-test
> 
>
> Key: TINKERPOP-1319
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1319
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> Several {{@FeatureRequirement}} annotations are incorrect in these 
> {{gremlin-test}} tests
> * EdgeTest.java
> * FeatureSupportTest.java
> * GraphTest.java
> * PropertyTest.java
> * VertexPropertyTest.java
> * VertexTest.java
> I'll submit a patch for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1319) several FeatureRequirement annotations are incorrect in gremlin-test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15367696#comment-15367696
 ] 

ASF GitHub Bot commented on TINKERPOP-1319:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/335


> several FeatureRequirement annotations are incorrect in gremlin-test
> 
>
> Key: TINKERPOP-1319
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1319
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> Several {{@FeatureRequirement}} annotations are incorrect in these 
> {{gremlin-test}} tests
> * EdgeTest.java
> * FeatureSupportTest.java
> * GraphTest.java
> * PropertyTest.java
> * VertexPropertyTest.java
> * VertexTest.java
> I'll submit a patch for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1254) Support dropping traverser path information when it is no longer needed.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15367673#comment-15367673
 ] 

ASF GitHub Bot commented on TINKERPOP-1254:
---

GitHub user twilmes opened a pull request:

https://github.com/apache/tinkerpop/pull/358

TINKERPOP-1254 Support dropping traverser path information when it is no 
longer needed

This PR adds support for path retraction to increase the likelihood of 
bulking in OLTP and OLAP modes. Traversal analysis is performed during the 
application of the PrunePathStrategy to identify labels that may be dropped at 
various points in the traversal.  MatchStep also performs runtime analysis to 
determine which labels it can drop in addition to the labels identified during 
traversal strategy application.

Here is a set of profiles showing the benefit of path dropping.  These were 
generated with `TinkerGraphComputer` first against 3.2 and then TinkerPop-1254. 
 **Note** that the times should not be compared here.  The first was run on my 
anemic macbook which, and the second was run on an 8 core AWS m3.2xlarge 
instance that I've been using for testing.  I'll be following up with more 
numbers on the same hardware but you can see here the dramatic drop in 
traversers with path pruning enabled.

**TP 3.2**
```
gremlin> g.V().match(__.as('a').out().as('b'), __.as('b').out().as('c'), 
__.as('c').out().as('d')).select('d').count().profile()
==>Traversal Metrics
Step   Count  
Traversers   Time (ms)% Dur

=
TinkerGraphStep(vertex,[])   808
 808  21.205 0.02
MatchStep(AND,[[MatchStartStep(a), ProfileStep,...  14465066
14465066  110317.81385.88
  MatchStartStep(a)  808
 808   10975.797
  VertexStep(OUT,vertex)8049
80496953.071
  MatchEndStep(b)   8049
80496727.167
  MatchStartStep(b) 8049
79575461.242
  VertexStep(OUT,vertex)  327370
  3273706782.024
  MatchEndStep(c) 327370
  3273706238.268
  MatchStartStep(c)   327370
  3269831771.773
  VertexStep(OUT,vertex)14465066
14465066   11489.228
  MatchEndStep(d)   14465066
14465066   14301.313
SelectOneStep(d)14465066
14465066   13752.96610.71
CountGlobalStep1
   14363.667 3.40
>TOTAL -
   -  128455.652-
```
 **TinkerPop-1254**
```
gremlin> g.V().match(__.as('a').out().as('b'), __.as('b').out().as('c'), 
__.as('c').out().as('d')).select('d').count().profile()
==>Traversal Metrics
Step   Count  
Traversers   Time (ms)% Dur

=
GraphStep(vertex,[]) 808
 808  32.45319.96
MatchStep(AND,[[MatchStartStep(a), ProfileStep,...  14465066
7510  89.46355.01
  MatchStartStep(a)  808
 808  22.388
  VertexStep(OUT,vertex)8049
7957  85.493
  MatchEndStep(b) (profiling ignored)   
   0.000
  MatchStartStep(b) 8049
 563   7.488
  VertexStep(OUT,vertex)  327370
7561  19.548
  MatchEndStep(c) (profiling ignored)   
   0.000
  MatchStartStep(c)   327370
 452   4.247
  VertexStep(OUT,vertex)14465066
7510  14.812
  MatchEndStep(d) (profiling ignored)   
   0.000
SelectOneStep(d)

[jira] [Commented] (TINKERPOP-1320) GremlinGroovyScriptEngineFileSandboxTest throws error: URI is not hierarchical

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15367700#comment-15367700
 ] 

ASF GitHub Bot commented on TINKERPOP-1320:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/336


> GremlinGroovyScriptEngineFileSandboxTest throws error: URI is not hierarchical
> --
>
> Key: TINKERPOP-1320
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1320
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> This is similar to TINKERPOP-1317. The differences here are
> * The {{TestHelper.generateTempFileFromResource()}} call to load the resource 
> is happening from the {{public static void init()}} method before a graph 
> instance is available.
> * A reference to {{GremlinGroovyScriptEngineFileSandboxTest.class}} is still 
> required to located the {{sandbox.yaml}} found in the {{gremlin-test.jar}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15367627#comment-15367627
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user newkek commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
@robertdale the format you suggest would lead to the same inconsistencies 
as in GraphSON 1.0. Since the type is at the same level than the data itself, 
whether the container is an Array or an Object, the type format would not be 
the same. I just pushed a change in the format that is the one @PommeVerte 
suggested, which gives a consistent format, without the concern of unordered 
Lists (for reference the new format is `{"@type" : "typeName", "@value" : 
value}`.

> please correct me if I'm wrong, but it doesn't look like the code does 
any dynamic serializing.

The `TypeIdResolver` which is the object that the serializers will call to 
get a TypeID from a java `Object` is dynamic in a way, in the sense that it 
returns `o.getClass().getSimpleName()`. So there is no `object` -> typeID index 
reference. However for the Deser, as explained in the description, Java by 
default doesn't offer a way to get a Class by its simple name, so the 
`TypeIdResolver` needs to keep a reference index of typeID(which is a class's 
simple name) -> Java `Class`. Don't know if that answers your question..


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1352) Connection Pool doesn't always grow

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15368106#comment-15368106
 ] 

ASF GitHub Bot commented on TINKERPOP-1352:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/352


> Connection Pool doesn't always grow 
> 
>
> Key: TINKERPOP-1352
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1352
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.3, 3.2.1
>
>
> With certain configurations (that aren't terribly intuitive) of the driver, 
> the connection pool won't grow properly - this includes the default 
> configuration. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1338) Bump to Groovy 2.4.7

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15368222#comment-15368222
 ] 

ASF GitHub Bot commented on TINKERPOP-1338:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/356


> Bump to Groovy 2.4.7
> 
>
> Key: TINKERPOP-1338
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1338
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.2.0-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Provides a number of bug fixes:
> http://groovy-lang.org/changelogs/changelog-2.4.7.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1338) Bump to Groovy 2.4.7

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364951#comment-15364951
 ] 

ASF GitHub Bot commented on TINKERPOP-1338:
---

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/356
  
I rebased to include @okram 's fix in the jira ticket.  4.5 hours later, 
"docker/build.sh -t -i -n" passed!


> Bump to Groovy 2.4.7
> 
>
> Key: TINKERPOP-1338
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1338
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.2.0-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Provides a number of bug fixes:
> http://groovy-lang.org/changelogs/changelog-2.4.7.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1319) several FeatureRequirement annotations are incorrect in gremlin-test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15365167#comment-15365167
 ] 

ASF GitHub Bot commented on TINKERPOP-1319:
---

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/335
  
```
[INFO] 

[INFO] Reactor Summary:
[INFO] 
[INFO] Apache TinkerPop .. SUCCESS [49.025s]
[INFO] Apache TinkerPop :: Gremlin Shaded  SUCCESS [10.134s]
[INFO] Apache TinkerPop :: Gremlin Core .. SUCCESS [33.447s]
[INFO] Apache TinkerPop :: Gremlin Test .. SUCCESS [8.743s]
[INFO] Apache TinkerPop :: Gremlin Groovy  SUCCESS 
[1:28.938s]
[INFO] Apache TinkerPop :: Gremlin Groovy Test ... SUCCESS [9.088s]
[INFO] Apache TinkerPop :: TinkerGraph Gremlin ... SUCCESS 
[4:05.011s]
[INFO] Apache TinkerPop :: Hadoop Gremlin  SUCCESS 
[6:23.000s]
[INFO] Apache TinkerPop :: Spark Gremlin . SUCCESS 
[13:38.044s]
[INFO] Apache TinkerPop :: Giraph Gremlin  SUCCESS 
[2:01:30.357s]
[INFO] Apache TinkerPop :: Neo4j Gremlin . SUCCESS 
[31:45.126s]
[INFO] Apache TinkerPop :: Gremlin Driver  SUCCESS [8.683s]
[INFO] Apache TinkerPop :: Gremlin Server  SUCCESS 
[12:03.655s]
[INFO] Apache TinkerPop :: Gremlin Console ... SUCCESS 
[1:57.427s]
[INFO] Apache TinkerPop :: Gremlin Archetype . SUCCESS [0.222s]
[INFO] Apache TinkerPop :: Archetype - TinkerGraph ... SUCCESS [16.966s]
[INFO] Apache TinkerPop :: Archetype - Server  SUCCESS [13.702s]
[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 3:15:22.725s
[INFO] Finished at: Wed Jul 06 21:31:50 UTC 2016
[INFO] Final Memory: 106M/275M
[INFO] 

Untagged: tinkerpop:build-1467828977
Deleted: 
sha256:fc0be61b8011cafa062bca435b24f0f1fa407d4891c2f93ca831ae5dd17c4184
Deleted: 
sha256:125d80aa8cb9f1988c9545af45434b45e997fa197a05e21ff0be06d31eb5c9f9
Deleted: 
sha256:ad8bc8dc69b8cf2e2d1a45d71ec3ceac476b10d9d410741157940a990ea54050
Deleted: 
sha256:4343aa626aa513ab75e38a1605adeb64bf8db026f4cc56b42b343b4798319a15
Deleted: 
sha256:94de2ed6571c94cbd0f154b71c7ca3f04d32e77228b79ed5922396ab4b340d62
Deleted: 
sha256:1915ffba96ed51ac0a85ba201be2c77eada5cb587b225841b0ae2841cb4403eb
```
Worked for me. Is this something I should wait on before committing?


> several FeatureRequirement annotations are incorrect in gremlin-test
> 
>
> Key: TINKERPOP-1319
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1319
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> Several {{@FeatureRequirement}} annotations are incorrect in these 
> {{gremlin-test}} tests
> * EdgeTest.java
> * FeatureSupportTest.java
> * GraphTest.java
> * PropertyTest.java
> * VertexPropertyTest.java
> * VertexTest.java
> I'll submit a patch for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1319) several FeatureRequirement annotations are incorrect in gremlin-test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15365238#comment-15365238
 ] 

ASF GitHub Bot commented on TINKERPOP-1319:
---

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/335
  
I'll rerun it too


> several FeatureRequirement annotations are incorrect in gremlin-test
> 
>
> Key: TINKERPOP-1319
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1319
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> Several {{@FeatureRequirement}} annotations are incorrect in these 
> {{gremlin-test}} tests
> * EdgeTest.java
> * FeatureSupportTest.java
> * GraphTest.java
> * PropertyTest.java
> * VertexPropertyTest.java
> * VertexTest.java
> I'll submit a patch for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1354) Include all static enum imports in request validation for bindings

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364460#comment-15364460
 ] 

ASF GitHub Bot commented on TINKERPOP-1354:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/354


> Include all static enum imports in request validation for bindings
> --
>
> Key: TINKERPOP-1354
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1354
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>  Labels: breaking
> Fix For: 3.1.3, 3.2.1
>
>
> Gremlin Server validates the bindings of incoming requests and returns an 
> error for any reserved terms. The list of reserved terms only includes {{T}} 
> but should also include others like {{Order}} and {{Scope}} so that users 
> don't inadvertently override them with a request binding. When that happens 
> Gremlin Server throws a not so easy to understand error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1350) Server locks when submitting parallel requests on session

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364393#comment-15364393
 ] 

ASF GitHub Bot commented on TINKERPOP-1350:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/350


> Server locks when submitting parallel requests on session
> -
>
> Key: TINKERPOP-1350
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1350
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.3, 3.2.1
>
>
> This really is only a problem when there is some form of long blocking script 
> submitted and only on a session when done in parallel, like:
> {code}
> final ResultSet first = client.submit(
> "Object mon1 = 'mon1';\n" +
> "synchronized (mon1) {\n" +
> "mon1.wait();\n" +
> "} ");
> final ResultSet second = client.submit(
> "Object mon2 = 'mon2';\n" +
> "synchronized (mon2) {\n" +
> "mon2.wait();\n" +
> "}");
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1319) several FeatureRequirement annotations are incorrect in gremlin-test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364346#comment-15364346
 ] 

ASF GitHub Bot commented on TINKERPOP-1319:
---

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/335
  
`docker/build.sh -t -i -n` fails for me in Spark Gremlin.


> several FeatureRequirement annotations are incorrect in gremlin-test
> 
>
> Key: TINKERPOP-1319
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1319
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> Several {{@FeatureRequirement}} annotations are incorrect in these 
> {{gremlin-test}} tests
> * EdgeTest.java
> * FeatureSupportTest.java
> * GraphTest.java
> * PropertyTest.java
> * VertexPropertyTest.java
> * VertexTest.java
> I'll submit a patch for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1254) Support dropping traverser path information when it is no longer needed.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369020#comment-15369020
 ] 

ASF GitHub Bot commented on TINKERPOP-1254:
---

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/358
  
`docker/build.sh -t -i -n` fails with:

```
Failed tests: 
  
DedupTest$Traversals>DedupTest.g_V_both_name_order_byXa_bX_dedup_value:110 
expected:<[josh]> but was:<[marko]>
```


> 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)
> 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 dropLabels = ...
>   final boolean dropPath = ...
>   public void sideEffect(final Traverser traverser) {
> final Traverser 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)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369151#comment-15369151
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
Note that I've started a new thread on the dev mailing list related to a 
new IO format with GLVs and Gremlin Server i mind:


https://lists.apache.org/thread.html/3d7bee51fcbf63051e687a3ab82075763154902e0baf4b1c75cb672e@%3Cdev.tinkerpop.apache.org%3E

If any of you have thoughts on the matter, please feel free to join the 
discussion there.


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369143#comment-15369143
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
I think we should try to merge this PR at this point (though we need one 
more +1 - @PommeVerte do you have a moment to do a final review?). There are a 
few little tweaks here and there, but I can quickly do those after we merge. 

I configured Gremlin Server to use 2.0 and it works nicely with REST:

```text
$ curl "http://localhost:8182?gremlin=g.V(1)"

{"requestId":"7b99b15e-5d07-4cb3-b9bd-cc62d03b99ca","status":{"message":"","code":200,"attributes":{}},"result":{"data":[{"id":{"@type":"Long","@value":1},"label":"person","type":"vertex","properties":{"name":[{"id":{"@type":"Long","@value":0},"value":"marko"}],"age":[{"id":{"@type":"Long","@value":2},"value":29}]}}],"meta":{}}}
```

I expect to do more tests around the server this week.

All tests pass with `docker/build.sh -t -n -i`

VOTE +1


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1360) intermittent error in spark-gremlin integration test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369653#comment-15369653
 ] 

ASF GitHub Bot commented on TINKERPOP-1360:
---

GitHub user pluradj opened a pull request:

https://github.com/apache/tinkerpop/pull/361

TINKERPOP-1360: compare vertex property ids as Long

https://issues.apache.org/jira/browse/TINKERPOP-1360

Verified with:

```
mvn clean install && mvn verify -q -DskipIntegrationTests=false -pl 
spark-gremlin
```

And via Docker
```
docker/build.sh -t -i -n
```

@spmallette @dkuppitz Please try out multiple times in your environments 
since the error only happens 1 out of 4 scenarios (based on 2 different 
`RANDOM.nextBooolean()` calls). I manually forced each scenario in by setting 
specific boolean values in `HadoopGraphProvider` and `SparkHadoopGraphProvider`.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1360

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/361.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #361


commit 30677963d4d5b74322796fb990161a94b43d00b1
Author: Jason Plurad 
Date:   2016-07-10T13:53:56Z

compare vertex property ids as Long




> intermittent error in spark-gremlin integration test
> 
>
> Key: TINKERPOP-1360
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1360
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
>
> This error intermittently comes up during the Spark integration tests
> {noformat}
> Tests run: 457, Failures: 1, Errors: 0, Skipped: 150, Time elapsed: 110.068 
> sec <<< FAILURE! - in 
> org.apache.tinkerpop.gremlin.spark.process.computer.SparkGraphComputerProcessIntegrateTest
> g_V_hasXageX_propertiesXnameX(org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesTest$Traversals)
>   Time elapsed: 0.185 sec  <<< FAILURE!
> java.lang.AssertionError: expected: java.lang.Integer<6> but was: 
> java.lang.Long<6>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesTest.g_V_hasXageX_propertiesXnameX(PropertiesTest.java:103)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at 
> org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:53)
>   at 
> org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:37)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:212)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at 

[jira] [Commented] (TINKERPOP-1254) Support dropping traverser path information when it is no longer needed.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
> 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 

[jira] [Commented] (TINKERPOP-1254) Support dropping traverser path information when it is no longer needed.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369701#comment-15369701
 ] 

ASF GitHub Bot commented on TINKERPOP-1254:
---

Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/358
  
I made a small update to `ReferencePath` to create new label Sets when a 
patch is detached.  This had been causing issues where the first set of labels 
for a path where being shared across `MutablePaths` after detachment.  A label 
would be removed from one, and therefore all of the traversers that had that 
label `Set` in their path, would be affected.

The `PathProcessors` are now respecting keepLabels null and labels are not 
dropped if `PrunePathStrategy` is not applied.

**PrunePathStrategy on**
```
g.V().match(
as("a").in("sungBy").as("b"),
as("a").in("sungBy").as("c"),
as("b").out("writtenBy").as("d"),
as("c").out("writtenBy").as("e"),
as("d").has("name", "George_Harrison"),
as("e").has("name", "Bob_Marley")).select("a").count().profile()

Traversal Metrics
Step   Count  
Traversers   Time (ms)% Dur

=
GraphStep(vertex,[]) 808
 808  44.21799.97
MatchStep(AND,[[MatchStartStep(a), ProfileStep,... 1
   1   0.004 0.01
  MatchStartStep(a)  808
 808  43.517
  VertexStep(IN,[sungBy],vertex) 501
 499  20.323
  MatchEndStep(b) (profiling ignored)   
   0.000
  MatchStartStep(a)2
   2   0.006
  VertexStep(IN,[sungBy],vertex) 156
 156   2.129
  MatchEndStep(c) (profiling ignored)   
   0.000
  MatchStartStep(b)  501
 499   5.126
  VertexStep(OUT,[writtenBy],vertex) 509
 504   3.423
  MatchEndStep(d) (profiling ignored)   
   0.000
  MatchStartStep(c)  156
 156   1.083
  VertexStep(OUT,[writtenBy],vertex) 157
 157   1.029
  MatchEndStep(e) (profiling ignored)   
   0.000
  MatchStartStep(d)  509
 266   1.685
  HasStep([name.eq(George_Harrison)])  2
   2   0.002
  MatchEndStep (profiling ignored)  
   0.000
  MatchStartStep(e)  157
  57   0.391
  HasStep([name.eq(Bob_Marley)])   1
   1   0.001
  MatchEndStep (profiling ignored)  
   0.000
SelectOneStep(a)   1
   1   0.003 0.01
CountGlobalStep1
   1   0.003 0.01
>TOTAL -
   -  44.228-
```
**PrunePathStrategy off**
```
Traversal Metrics
Step   Count  
Traversers   Time (ms)% Dur

=
GraphStep(vertex,[]) 808
 808   7.56599.84
MatchStep(AND,[[MatchStartStep(a), ProfileStep,... 1
   1   0.007 0.10
  MatchStartStep(a)  808
 808   5.726
  VertexStep(IN,[sungBy],vertex) 501
 499   9.532
  MatchEndStep(b) (profiling ignored)   
   0.000
  MatchStartStep(a)2
   2   0.007
  VertexStep(IN,[sungBy],vertex) 156
 156   1.803
  

[jira] [Commented] (TINKERPOP-1360) intermittent error in spark-gremlin integration test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15370626#comment-15370626
 ] 

ASF GitHub Bot commented on TINKERPOP-1360:
---

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/361
  
Dunno, is this really a fix or do we simply ignore a flaw? I mean why do we 
have to cast result types at all?


> intermittent error in spark-gremlin integration test
> 
>
> Key: TINKERPOP-1360
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1360
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
>
> This error intermittently comes up during the Spark integration tests
> {noformat}
> Tests run: 457, Failures: 1, Errors: 0, Skipped: 150, Time elapsed: 110.068 
> sec <<< FAILURE! - in 
> org.apache.tinkerpop.gremlin.spark.process.computer.SparkGraphComputerProcessIntegrateTest
> g_V_hasXageX_propertiesXnameX(org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesTest$Traversals)
>   Time elapsed: 0.185 sec  <<< FAILURE!
> java.lang.AssertionError: expected: java.lang.Integer<6> but was: 
> java.lang.Long<6>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesTest.g_V_hasXageX_propertiesXnameX(PropertiesTest.java:103)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at 
> org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:53)
>   at 
> org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:37)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:212)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> Reproduce steps:
> {noformat}
> mvn verify -q -DskipIntegrationTests=false -pl spark-gremlin
> {noformat}
> Environments used:
> {noformat}
> Apache Maven 3.0.5
> 

[jira] [Commented] (TINKERPOP-1360) intermittent error in spark-gremlin integration test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15370657#comment-15370657
 ] 

ASF GitHub Bot commented on TINKERPOP-1360:
---

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/361
  
In the failing scenario, you have GraphSONRecordReader pulling in the graph 
and using Integer as the id type (via Jackson in GraphSONReader). It is getting 
compared against a graph from ToyGraphInputRDD which uses Long as the id type 
(via TinkerGraph default id manager). `equals()` comparison of the same value 
`6` fails because the types are different.

```java.lang.AssertionError: expected: java.lang.Integer<6> but was: 
java.lang.Long<6>```

Switching to `tinkerpop-modern-typed.json` instead of 
`tinkerpop-modern.json` doesn't help the situation since the id type isn't 
stored.


> intermittent error in spark-gremlin integration test
> 
>
> Key: TINKERPOP-1360
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1360
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
>
> This error intermittently comes up during the Spark integration tests
> {noformat}
> Tests run: 457, Failures: 1, Errors: 0, Skipped: 150, Time elapsed: 110.068 
> sec <<< FAILURE! - in 
> org.apache.tinkerpop.gremlin.spark.process.computer.SparkGraphComputerProcessIntegrateTest
> g_V_hasXageX_propertiesXnameX(org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesTest$Traversals)
>   Time elapsed: 0.185 sec  <<< FAILURE!
> java.lang.AssertionError: expected: java.lang.Integer<6> but was: 
> java.lang.Long<6>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesTest.g_V_hasXageX_propertiesXnameX(PropertiesTest.java:103)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at 
> org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:53)
>   at 
> org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:37)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:212)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> 

[jira] [Commented] (TINKERPOP-1360) intermittent error in spark-gremlin integration test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15370684#comment-15370684
 ] 

ASF GitHub Bot commented on TINKERPOP-1360:
---

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/361
  
I see.. I guess it can be considered to be a "fix" then ;)

VOTE: +1


> intermittent error in spark-gremlin integration test
> 
>
> Key: TINKERPOP-1360
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1360
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
>
> This error intermittently comes up during the Spark integration tests
> {noformat}
> Tests run: 457, Failures: 1, Errors: 0, Skipped: 150, Time elapsed: 110.068 
> sec <<< FAILURE! - in 
> org.apache.tinkerpop.gremlin.spark.process.computer.SparkGraphComputerProcessIntegrateTest
> g_V_hasXageX_propertiesXnameX(org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesTest$Traversals)
>   Time elapsed: 0.185 sec  <<< FAILURE!
> java.lang.AssertionError: expected: java.lang.Integer<6> but was: 
> java.lang.Long<6>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> org.apache.tinkerpop.gremlin.process.traversal.step.map.PropertiesTest.g_V_hasXageX_propertiesXnameX(PropertiesTest.java:103)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at 
> org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:53)
>   at 
> org.apache.tinkerpop.gremlin.process.GremlinProcessRunner.runChild(GremlinProcessRunner.java:37)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:212)
>   at 
> org.apache.tinkerpop.gremlin.AbstractGremlinSuite.runChild(AbstractGremlinSuite.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> Reproduce steps:
> {noformat}
> mvn verify -q -DskipIntegrationTests=false -pl spark-gremlin
> {noformat}
> Environments used:
> {noformat}
> Apache Maven 3.0.5
> Maven home: /usr/share/maven
> 

[jira] [Commented] (TINKERPOP-1319) several FeatureRequirement annotations are incorrect in gremlin-test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15366710#comment-15366710
 ] 

ASF GitHub Bot commented on TINKERPOP-1319:
---

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/335
  
https://issues.apache.org/jira/browse/TINKERPOP-1360


> several FeatureRequirement annotations are incorrect in gremlin-test
> 
>
> Key: TINKERPOP-1319
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1319
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> Several {{@FeatureRequirement}} annotations are incorrect in these 
> {{gremlin-test}} tests
> * EdgeTest.java
> * FeatureSupportTest.java
> * GraphTest.java
> * PropertyTest.java
> * VertexPropertyTest.java
> * VertexTest.java
> I'll submit a patch for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1338) Bump to Groovy 2.4.7

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15367478#comment-15367478
 ] 

ASF GitHub Bot commented on TINKERPOP-1338:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/356
  
All tests pass with `docker/build.sh -t -n -i`

VOTE +1


> Bump to Groovy 2.4.7
> 
>
> Key: TINKERPOP-1338
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1338
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.2.0-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Provides a number of bug fixes:
> http://groovy-lang.org/changelogs/changelog-2.4.7.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362655#comment-15362655
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user newkek commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
Well, I agree we cannot prevent some parsers and drivers to read the whole 
JSON content and check the created object only afterward. I would not recommend 
it though, because it is not great for memory consumption, but it is maybe 
something we have the opportunity to avoid only thanks to Jackson and some 
libraries may not offer that capability. So I guess I'll switch to the 
`{"@type":"...", "value": ...}` format instead of the current one. Does that 
sound good @spmallette @PommeVerte ?


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362664#comment-15362664
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
This change is largely to help the consumption of GraphSON by non-JVM 
languages. Since I'm largely familiar with the behaviors of java based parsers 
and such, i'm not a good judge of that so i have to rely on @PommeVerte and 
others in this area. If the switch to Map is helpful then I think we should go 
that route. @newkek I would not be hasty in the change though. Perhaps we give 
it a day or so to think about to be sure that everyone is happy with that 
approach before you make the change and commit to it.


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1352) Connection Pool doesn't always grow

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361375#comment-15361375
 ] 

ASF GitHub Bot commented on TINKERPOP-1352:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/352
  
nice find @robertdale - i pushed a fix that removed that assert. that whole 
test case is deprecated anyway, so i'm not too worried about it. 

@ramzioueslati care to pull the branch again and give it another go?


> Connection Pool doesn't always grow 
> 
>
> Key: TINKERPOP-1352
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1352
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.3, 3.2.1
>
>
> With certain configurations (that aren't terribly intuitive) of the driver, 
> the connection pool won't grow properly - this includes the default 
> configuration. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1352) Connection Pool doesn't always grow

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361483#comment-15361483
 ] 

ASF GitHub Bot commented on TINKERPOP-1352:
---

Github user ramzioueslati commented on the issue:

https://github.com/apache/tinkerpop/pull/352
  
Will do right away.

For the record here is the stacktrace:
```
Running 
org.apache.tinkerpop.gremlin.server.GremlinServerAuthOldIntegrateTest
[WARN] org.apache.tinkerpop.gremlin.server.auth.SimpleAuthenticator - Using 
{} configuration option which is deprecated - prefer including the location of 
the credentials graph data in the TinkerGraph config file.
[WARN] org.apache.tinkerpop.gremlin.server.auth.SimpleAuthenticator - Using 
{} configuration option which is deprecated - prefer including the location of 
the credentials graph data in the TinkerGraph config file.
[WARN] org.apache.tinkerpop.gremlin.server.auth.SimpleAuthenticator - Using 
{} configuration option which is deprecated - prefer including the location of 
the credentials graph data in the TinkerGraph config file.
[WARN] org.apache.tinkerpop.gremlin.server.AbstractChannelizer - Enabling 
SSL with self-signed certificate (NOT SUITABLE FOR PRODUCTION)
[WARN] org.apache.tinkerpop.gremlin.server.auth.SimpleAuthenticator - Using 
{} configuration option which is deprecated - prefer including the location of 
the credentials graph data in the TinkerGraph config file.
[WARN] org.apache.tinkerpop.gremlin.driver.Cluster - SSL configured without 
a trustCertChainFile and thus trusts all certificates without verification (not 
suitable for production)
[WARN] org.apache.tinkerpop.gremlin.driver.Cluster - SSL configured without 
a trustCertChainFile and thus trusts all certificates without verification (not 
suitable for production)
[WARN] org.apache.tinkerpop.gremlin.server.auth.SimpleAuthenticator - Using 
{} configuration option which is deprecated - prefer including the location of 
the credentials graph data in the TinkerGraph config file.
[WARN] org.apache.tinkerpop.gremlin.server.auth.SimpleAuthenticator - Using 
{} configuration option which is deprecated - prefer including the location of 
the credentials graph data in the TinkerGraph config file.
[ERROR] org.apache.tinkerpop.gremlin.driver.Handler$GremlinResponseHandler 
- Could not process the response
javax.security.sasl.SaslException: GSS initiate failed [Caused by 
GSSException: No valid credentials provided (Mechanism level: Failed to find 
any Kerberos tgt)]
at 
com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:211)
at 
org.apache.tinkerpop.gremlin.driver.Handler$GremlinSaslAuthenticationHandler.evaluateChallenge(Handler.java:123)
at 
org.apache.tinkerpop.gremlin.driver.Handler$GremlinSaslAuthenticationHandler.channelRead0(Handler.java:93)
at 
org.apache.tinkerpop.gremlin.driver.Handler$GremlinSaslAuthenticationHandler.channelRead0(Handler.java:66)
at 
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:307)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:293)
at 
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:307)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:293)
at 
org.apache.tinkerpop.gremlin.driver.handler.WebSocketClientHandler.channelRead0(WebSocketClientHandler.java:90)
at 
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:307)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:293)
at 
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:276)
at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:263)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:307)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:293)
at 
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:840)
at 
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
at 

[jira] [Commented] (TINKERPOP-1352) Connection Pool doesn't always grow

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361508#comment-15361508
 ] 

ASF GitHub Bot commented on TINKERPOP-1352:
---

Github user ramzioueslati commented on the issue:

https://github.com/apache/tinkerpop/pull/352
  
Successful pass


> Connection Pool doesn't always grow 
> 
>
> Key: TINKERPOP-1352
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1352
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.3, 3.2.1
>
>
> With certain configurations (that aren't terribly intuitive) of the driver, 
> the connection pool won't grow properly - this includes the default 
> configuration. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1355) Design HasContainer for extension

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362473#comment-15362473
 ] 

ASF GitHub Bot commented on TINKERPOP-1355:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/355
  
Clean changes. VOTE +1.


> Design HasContainer for extension
> -
>
> Key: TINKERPOP-1355
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1355
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Bryn Cooke
>Priority: Critical
>
> Currently HasContainer is final. This means that Graph implementations cannot 
> support their own type systems across the entire traversal.
> Given the traversal:
> g.V.has('foo', nonTinkerpopType).out('bar').has('foo', nonTinkerpopType)
> Say that the initial traversal g.V.has('foo', nonTinkerpopType) is dealt with 
> via strategy, the non-Tinkerpop type can be dealt with. However the rest of 
> the traversal is processed via the default Tinkerpop pipeline, and as such it 
> doesn't know how to deal with type conversions/comparisons etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1400) SubgraphStrategy introduces infinite recursion if filter has Vertex/Edge steps.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409951#comment-15409951
 ] 

ASF GitHub Bot commented on TINKERPOP-1400:
---

Github user analytically commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/374#discussion_r73747869
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/decoration/SubgraphStrategy.java
 ---
@@ -156,20 +182,36 @@ private static void transferLabels(final Step from, 
final Step to) {
 private Builder() {
 }
 
-public Builder vertexCriterion(final Traversal 
predicate) {
-vertexCriterion = predicate;
+public Builder vertices(final Traversal 
vertexPredicate) {
+this.vertexCriterion = vertexPredicate;
--- End diff --

Best rename the local vertexCriterion to vertexPredicate too no?


> SubgraphStrategy introduces infinite recursion if filter has Vertex/Edge 
> steps.
> ---
>
> Key: TINKERPOP-1400
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1400
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> James from the mailing list reported:
> {code}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> s = SubgraphStrategy.build().vertexCriterion(hasId(1)).create()
> ==>SubgraphStrategy
> gremlin> g.V().filter(hasId(1))
> ==>v[1]
> gremlin> g.withStrategies(s).V()
> ==>v[1]
> works as expected. But if I change the predicate traversal to something 
> slightly more complex, e.g. in('knows').hasId(1) things start to go haywire.
> The single step predicates works as expected in 3.1.1-incubating, 3.1.3 and 
> 3.2.1.
> In 3.1.1-incubating the multi-step predicate subgraph strategy seems to end 
> up generating the same traversal as using filter(...) but fails to execute:
> $ sh apache-gremlin-console-3.1.1-incubating/bin/gremlin.sh 
>  \,,,/
>  (o o)
> -oOOo-(3)-oOOo-
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.tinkergraph
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> s = 
> SubgraphStrategy.build().vertexCriterion(__.in('knows').hasId(1)).create()
> ==>SubgraphStrategy
> gremlin> g1 = GraphTraversalSource.build().with(s).create(graph)
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().filter(__.in('knows').hasId(1)).explain()
> ==>Traversal Explanation
> ===
> Original Traversal [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> ConnectiveStrategy   [D]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> IdentityRemovalStrategy  [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> IncidentToAdjacentStrategy   [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> AdjacentToIncidentStrategy   [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> FilterRankingStrategy[O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> MatchPredicateStrategy   [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> RangeByIsCountStrategy   [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> TinkerGraphStepStrategy  [P]   [TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> EngineDependentStrategy  [F]   [TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> ProfileStrategy  [F]   [TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> StandardVerificationStrategy [V]   [TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> ComputerVerificationStrategy [V]   

[jira] [Commented] (TINKERPOP-1400) SubgraphStrategy introduces infinite recursion if filter has Vertex/Edge steps.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15409927#comment-15409927
 ] 

ASF GitHub Bot commented on TINKERPOP-1400:
---

GitHub user okram opened a pull request:

https://github.com/apache/tinkerpop/pull/374

TINKERPOP-1400: SubgraphStrategy introduces infinite recursion if filter 
has Vertex/Edge steps.

https://issues.apache.org/jira/browse/TINKERPOP-1400

There was a severe bug in SubgraphStrategy where the traversal filters that 
were added for sub-graphing were being recursively applied yielded a 
StackOverflow. We did not have complex enough tests in 
SubgraphStrategyProcessTest to illicit the bug. The fix is clever using Step 
label markers to know if a traversal whose is having their strategy applied is 
a vertex/edge subgraph filter. Its clever.

* Note: given the differences in strategy application code, this can not 
easily go into the `tp31`-line without a rewrite. Thus, this is headed to 
`master/`.

CHANGELOG

```
* Fixed a severe bug in `SubgraphStrategy`.
* Deprecated `SubgraphStrategy.Builder.vertexCriterion()/edgeCriterion()` 
in favor of `vertices()/edges()`.
```

VOTE +1.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1400

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/374.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #374


commit 9d6a4957468a65d15180ddc31f5020255ad14f20
Author: Marko A. Rodriguez 
Date:   2016-08-05T19:16:58Z

Fixed a severe bug in SubgraphStrategy where infinite recurssion occurs if 
the strategy is not smart about how child traverals with Vertex/EdgeSteps are 
analyzed. Also Deprecated vertexCriteria() method with vertices() likewise for 
edgeCritera() in SubGraphStrategy.Builder to be consistent with GraphFilter 
style (same concept). In fact, moving forward, SubGraphStrategy could take a 
GraphFilter.




> SubgraphStrategy introduces infinite recursion if filter has Vertex/Edge 
> steps.
> ---
>
> Key: TINKERPOP-1400
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1400
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> James from the mailing list reported:
> {code}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> s = SubgraphStrategy.build().vertexCriterion(hasId(1)).create()
> ==>SubgraphStrategy
> gremlin> g.V().filter(hasId(1))
> ==>v[1]
> gremlin> g.withStrategies(s).V()
> ==>v[1]
> works as expected. But if I change the predicate traversal to something 
> slightly more complex, e.g. in('knows').hasId(1) things start to go haywire.
> The single step predicates works as expected in 3.1.1-incubating, 3.1.3 and 
> 3.2.1.
> In 3.1.1-incubating the multi-step predicate subgraph strategy seems to end 
> up generating the same traversal as using filter(...) but fails to execute:
> $ sh apache-gremlin-console-3.1.1-incubating/bin/gremlin.sh 
>  \,,,/
>  (o o)
> -oOOo-(3)-oOOo-
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.tinkergraph
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> s = 
> SubgraphStrategy.build().vertexCriterion(__.in('knows').hasId(1)).create()
> ==>SubgraphStrategy
> gremlin> g1 = GraphTraversalSource.build().with(s).create(graph)
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().filter(__.in('knows').hasId(1)).explain()
> ==>Traversal Explanation
> ===
> Original Traversal [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> ConnectiveStrategy   [D]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> IdentityRemovalStrategy  [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> IncidentToAdjacentStrategy   [O]   [GraphStep([],vertex), 
> 

[jira] [Commented] (TINKERPOP-1379) unaccounted excess in TailGlobalStep

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15408294#comment-15408294
 ] 

ASF GitHub Bot commented on TINKERPOP-1379:
---

Github user okram commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/366#discussion_r73580040
  
--- Diff: 
gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/TailTest.java
 ---
@@ -120,6 +123,19 @@ public void g_V_repeatXbothX_timesX3X_tailX7X() {
 assertEquals(7, counter);
 }
 
+/** Scenario: Global scope, using repeat (excess BULK) */
+@Test
+@LoadGraphWith(MODERN)
+public void g_V_repeatXin_outX_timesX3X_tailX7X_count() {
+final Traversal traversal = 
get_g_V_repeatXin_outX_timesX3X_tailX7X_count();
+printTraversalForm(traversal);
+long count = 0L;
--- End diff --

This is as easy as:

```
checkResults(Collections.singleList(7L), traversal)
```

It will also verify `hasNext() == false` at the end.


> unaccounted excess in TailGlobalStep
> 
>
> Key: TINKERPOP-1379
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1379
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.0.2-incubating, 3.1.3, 3.2.1
>Reporter: Jason Plurad
> Fix For: 3.1.4, 3.2.2, 3.3.0
>
>
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/TailGlobalStep.java#L71-L74
> This code doesn't account for the excess removed from {{tailBulk}}. This can 
> cause the code to set incorrect bulk values when there are multiple 
> traversers in the tail buffer.
> I observed this behavior intermittently in TitanGraph 
> (https://github.com/thinkaurelius/titan/pull/1312), which doesn't allow user 
> defined ids, so the ordering of the traversers in the TraverserSet is a lot 
> more random than the unit tests using TinkerGraph.
> This issue is reproducible with TinkerGraph (master/3.2.1). Instead of 
> loading from one of the data files, manually create the graph with the ids in 
> inverted order.
> {noformat}
> graph = TinkerGraph.open();
> // graph.io(IoCore.gryo()).readGraph("tinkerpop-modern.kryo");
> final Vertex v1 = graph.addVertex(T.id, 6L, T.label, "person", "name", 
> "marko", "age", 29);
> final Vertex v2 = graph.addVertex(T.id, 5L, T.label, "person", "name", 
> "vadas", "age", 27);
> final Vertex v3 = graph.addVertex(T.id, 4L, T.label, "software", "name", 
> "lop", "lang", "java");
> final Vertex v4 = graph.addVertex(T.id, 3L, T.label, "person", "name", 
> "josh", "age", 32);
> final Vertex v5 = graph.addVertex(T.id, 2L, T.label, "software", "name", 
> "ripple", "lang", "java");
> final Vertex v6 = graph.addVertex(T.id, 1L, T.label, "person", "name", 
> "peter", "age", 35);
> v1.addEdge("knows", v2, "weight", 0.5d);
> v1.addEdge("knows", v4, "weight", 1.0d);
> v1.addEdge("created", v2, "weight", 0.4d);
> v4.addEdge("knows", v5, "weight", 1.0d);
> v4.addEdge("knows", v3, "weight", 0.4d);
> v6.addEdge("knows", v3, "weight", 0.2d);
> if (graph.features().graph().supportsTransactions()) graph.tx().commit();
> final GraphTraversalSource g = graph.traversal();
> String result = 
> g.V().repeat(both()).times(3).tail(7).count().next().toString();
> boolean success = "7".equals(result);
> {noformat}
> The fix is this:
> {noformat}
> if (excess > 0) {
> oldest.setBulk(oldestBulk-excess);
> // Account for the loss of excess in the tail buffer
> this.tailBulk -= excess;
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1400) SubgraphStrategy introduces infinite recursion if filter has Vertex/Edge steps.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15411945#comment-15411945
 ] 

ASF GitHub Bot commented on TINKERPOP-1400:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/374
  
All tests pass with `docker/build.sh -t -n -i`

VOTE +1


> SubgraphStrategy introduces infinite recursion if filter has Vertex/Edge 
> steps.
> ---
>
> Key: TINKERPOP-1400
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1400
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> James from the mailing list reported:
> {code}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> s = SubgraphStrategy.build().vertexCriterion(hasId(1)).create()
> ==>SubgraphStrategy
> gremlin> g.V().filter(hasId(1))
> ==>v[1]
> gremlin> g.withStrategies(s).V()
> ==>v[1]
> works as expected. But if I change the predicate traversal to something 
> slightly more complex, e.g. in('knows').hasId(1) things start to go haywire.
> The single step predicates works as expected in 3.1.1-incubating, 3.1.3 and 
> 3.2.1.
> In 3.1.1-incubating the multi-step predicate subgraph strategy seems to end 
> up generating the same traversal as using filter(...) but fails to execute:
> $ sh apache-gremlin-console-3.1.1-incubating/bin/gremlin.sh 
>  \,,,/
>  (o o)
> -oOOo-(3)-oOOo-
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.tinkergraph
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> s = 
> SubgraphStrategy.build().vertexCriterion(__.in('knows').hasId(1)).create()
> ==>SubgraphStrategy
> gremlin> g1 = GraphTraversalSource.build().with(s).create(graph)
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().filter(__.in('knows').hasId(1)).explain()
> ==>Traversal Explanation
> ===
> Original Traversal [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> ConnectiveStrategy   [D]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> IdentityRemovalStrategy  [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> IncidentToAdjacentStrategy   [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> AdjacentToIncidentStrategy   [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> FilterRankingStrategy[O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> MatchPredicateStrategy   [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> RangeByIsCountStrategy   [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> TinkerGraphStepStrategy  [P]   [TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> EngineDependentStrategy  [F]   [TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> ProfileStrategy  [F]   [TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> StandardVerificationStrategy [V]   [TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> ComputerVerificationStrategy [V]   [TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> Final Traversal[TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> gremlin> g.V().filter(__.in('knows').hasId(1))
> ==>v[2]
> ==>v[4]
> gremlin> g1.V().explain()
> ==>Traversal Explanation
> ===
> Original Traversal [GraphStep([],vertex)]
> ConnectiveStrategy   [D]   

[jira] [Commented] (TINKERPOP-1350) Server locks when submitting parallel requests on session

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410090#comment-15410090
 ] 

ASF GitHub Bot commented on TINKERPOP-1350:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/367
  
VOTE +1.


> Server locks when submitting parallel requests on session
> -
>
> Key: TINKERPOP-1350
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1350
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.4, 3.2.2
>
>
> This really is only a problem when there is some form of long blocking script 
> submitted and only on a session when done in parallel, like:
> {code}
> final ResultSet first = client.submit(
> "Object mon1 = 'mon1';\n" +
> "synchronized (mon1) {\n" +
> "mon1.wait();\n" +
> "} ");
> final ResultSet second = client.submit(
> "Object mon2 = 'mon2';\n" +
> "synchronized (mon2) {\n" +
> "mon2.wait();\n" +
> "}");
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1400) SubgraphStrategy introduces infinite recursion if filter has Vertex/Edge steps.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413410#comment-15413410
 ] 

ASF GitHub Bot commented on TINKERPOP-1400:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/374


> SubgraphStrategy introduces infinite recursion if filter has Vertex/Edge 
> steps.
> ---
>
> Key: TINKERPOP-1400
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1400
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> James from the mailing list reported:
> {code}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> s = SubgraphStrategy.build().vertexCriterion(hasId(1)).create()
> ==>SubgraphStrategy
> gremlin> g.V().filter(hasId(1))
> ==>v[1]
> gremlin> g.withStrategies(s).V()
> ==>v[1]
> works as expected. But if I change the predicate traversal to something 
> slightly more complex, e.g. in('knows').hasId(1) things start to go haywire.
> The single step predicates works as expected in 3.1.1-incubating, 3.1.3 and 
> 3.2.1.
> In 3.1.1-incubating the multi-step predicate subgraph strategy seems to end 
> up generating the same traversal as using filter(...) but fails to execute:
> $ sh apache-gremlin-console-3.1.1-incubating/bin/gremlin.sh 
>  \,,,/
>  (o o)
> -oOOo-(3)-oOOo-
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.tinkergraph
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> s = 
> SubgraphStrategy.build().vertexCriterion(__.in('knows').hasId(1)).create()
> ==>SubgraphStrategy
> gremlin> g1 = GraphTraversalSource.build().with(s).create(graph)
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().filter(__.in('knows').hasId(1)).explain()
> ==>Traversal Explanation
> ===
> Original Traversal [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> ConnectiveStrategy   [D]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> IdentityRemovalStrategy  [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> IncidentToAdjacentStrategy   [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> AdjacentToIncidentStrategy   [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> FilterRankingStrategy[O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> MatchPredicateStrategy   [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> RangeByIsCountStrategy   [O]   [GraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> TinkerGraphStepStrategy  [P]   [TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> EngineDependentStrategy  [F]   [TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> ProfileStrategy  [F]   [TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> StandardVerificationStrategy [V]   [TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> ComputerVerificationStrategy [V]   [TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> Final Traversal[TinkerGraphStep([],vertex), 
> TraversalFilterStep([VertexStep(IN,[knows],vertex), HasStep([~id.eq(1)])])]
> gremlin> g.V().filter(__.in('knows').hasId(1))
> ==>v[2]
> ==>v[4]
> gremlin> g1.V().explain()
> ==>Traversal Explanation
> ===
> Original Traversal [GraphStep([],vertex)]
> ConnectiveStrategy   [D]   [GraphStep([],vertex)]
> SubgraphStrategy [D]   [GraphStep([],vertex), 
> 

[jira] [Commented] (TINKERPOP-1379) unaccounted excess in TailGlobalStep

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15411703#comment-15411703
 ] 

ASF GitHub Bot commented on TINKERPOP-1379:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/366
  
All good with a quick `mvn clean install`

VOTE +1  - pending fix @okram suggested for the test code and what looks 
like the need for a rebase given conflicts that are likely on changelog.


> unaccounted excess in TailGlobalStep
> 
>
> Key: TINKERPOP-1379
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1379
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.0.2-incubating, 3.1.3, 3.2.1
>Reporter: Jason Plurad
> Fix For: 3.1.4, 3.2.2, 3.3.0
>
>
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/TailGlobalStep.java#L71-L74
> This code doesn't account for the excess removed from {{tailBulk}}. This can 
> cause the code to set incorrect bulk values when there are multiple 
> traversers in the tail buffer.
> I observed this behavior intermittently in TitanGraph 
> (https://github.com/thinkaurelius/titan/pull/1312), which doesn't allow user 
> defined ids, so the ordering of the traversers in the TraverserSet is a lot 
> more random than the unit tests using TinkerGraph.
> This issue is reproducible with TinkerGraph (master/3.2.1). Instead of 
> loading from one of the data files, manually create the graph with the ids in 
> inverted order.
> {noformat}
> graph = TinkerGraph.open();
> // graph.io(IoCore.gryo()).readGraph("tinkerpop-modern.kryo");
> final Vertex v1 = graph.addVertex(T.id, 6L, T.label, "person", "name", 
> "marko", "age", 29);
> final Vertex v2 = graph.addVertex(T.id, 5L, T.label, "person", "name", 
> "vadas", "age", 27);
> final Vertex v3 = graph.addVertex(T.id, 4L, T.label, "software", "name", 
> "lop", "lang", "java");
> final Vertex v4 = graph.addVertex(T.id, 3L, T.label, "person", "name", 
> "josh", "age", 32);
> final Vertex v5 = graph.addVertex(T.id, 2L, T.label, "software", "name", 
> "ripple", "lang", "java");
> final Vertex v6 = graph.addVertex(T.id, 1L, T.label, "person", "name", 
> "peter", "age", 35);
> v1.addEdge("knows", v2, "weight", 0.5d);
> v1.addEdge("knows", v4, "weight", 1.0d);
> v1.addEdge("created", v2, "weight", 0.4d);
> v4.addEdge("knows", v5, "weight", 1.0d);
> v4.addEdge("knows", v3, "weight", 0.4d);
> v6.addEdge("knows", v3, "weight", 0.2d);
> if (graph.features().graph().supportsTransactions()) graph.tx().commit();
> final GraphTraversalSource g = graph.traversal();
> String result = 
> g.V().repeat(both()).times(3).tail(7).count().next().toString();
> boolean success = "7".equals(result);
> {noformat}
> The fix is this:
> {noformat}
> if (excess > 0) {
> oldest.setBulk(oldestBulk-excess);
> // Account for the loss of excess in the tail buffer
> this.tailBulk -= excess;
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1350) Server locks when submitting parallel requests on session

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15411657#comment-15411657
 ] 

ASF GitHub Bot commented on TINKERPOP-1350:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/367


> Server locks when submitting parallel requests on session
> -
>
> Key: TINKERPOP-1350
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1350
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.4, 3.2.2
>
>
> This really is only a problem when there is some form of long blocking script 
> submitted and only on a session when done in parallel, like:
> {code}
> final ResultSet first = client.submit(
> "Object mon1 = 'mon1';\n" +
> "synchronized (mon1) {\n" +
> "mon1.wait();\n" +
> "} ");
> final ResultSet second = client.submit(
> "Object mon2 = 'mon2';\n" +
> "synchronized (mon2) {\n" +
> "mon2.wait();\n" +
> "}");
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1350) Server locks when submitting parallel requests on session

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15404681#comment-15404681
 ] 

ASF GitHub Bot commented on TINKERPOP-1350:
---

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/367

TINKERPOP-1350 was never quite fixed in 3.1.3.

Unfortunately, more testing revealed that the fix for the problem was only 
masked by the changes in 3.1.3. 

Changed response encoding to not use the session executor when the session 
has an error condition it is trying to serialize. This should be fine as there 
is no need to serialized an error condition as part of a transaction and thus 
no need to have the session thread to do it. That in turn frees up the worker 
executor to serialize and cancel long run jobs in the session. Removed 
recommendations for submitting parallel requests on a session from docs.

Works in full with `mvn clean install && mvn verify -pl gremlin-server 
-DskipIntegrationTests=false`

VOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1350

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/367.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #367


commit 57ef449ded52e5c11072e7a626eebcfcc13889c4
Author: Stephen Mallette 
Date:   2016-08-02T19:59:19Z

TINKERPOP-1350 was never quite fixed in 3.1.3.

Changed response encoding to not use the session executor when the session 
has an error condition it is trying to serialize. This should be fine as there 
is no need to serialized an error condition as part of a transaction and thus 
no need to have the session thread to do it. That in turn frees up the worker 
executor to serialize and cancel long run jobs in the session. Removed 
recommendations for submitting parallel requests on a session from docs.




> Server locks when submitting parallel requests on session
> -
>
> Key: TINKERPOP-1350
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1350
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.4, 3.2.2
>
>
> This really is only a problem when there is some form of long blocking script 
> submitted and only on a session when done in parallel, like:
> {code}
> final ResultSet first = client.submit(
> "Object mon1 = 'mon1';\n" +
> "synchronized (mon1) {\n" +
> "mon1.wait();\n" +
> "} ");
> final ResultSet second = client.submit(
> "Object mon2 = 'mon2';\n" +
> "synchronized (mon2) {\n" +
> "mon2.wait();\n" +
> "}");
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414267#comment-15414267
 ] 

ASF GitHub Bot commented on TINKERPOP-1278:
---

Github user leifurhauks commented on the issue:

https://github.com/apache/tinkerpop/pull/357
  
Okay, should be good now


> Implement Gremlin-Python and general purpose language variant test 
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language 
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model 
> presented in 
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
>  Moreover, on every {{mvn clean install}}, the code for these variants is 
> generated.
> Given the desire to separate language variants from language drivers, I think 
> that a language driver for each variant above should be "plugable." Moreover, 
> we should provide one driver implementation for each -- simple GremlinServer 
> REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
>   gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
>   gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we 
> have to implement each {{g_V_out_repeatXasXaXX}} test case in 
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to 
> convert all those tests from Gremlin-Java to the respective host language? 
> However, even if we do that, we still have the problem of how to test the 
> returned results. 
> I think what we should test the returned results using the JVM. For instance, 
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a 
> massive headache. All we have to do is create a {{GraphProvider}} that uses 
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around 
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the 
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb   // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414252#comment-15414252
 ] 

ASF GitHub Bot commented on TINKERPOP-1278:
---

Github user leifurhauks commented on the issue:

https://github.com/apache/tinkerpop/pull/357
  
Brought this branch up to date and fixed the code generators.


> Implement Gremlin-Python and general purpose language variant test 
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language 
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model 
> presented in 
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
>  Moreover, on every {{mvn clean install}}, the code for these variants is 
> generated.
> Given the desire to separate language variants from language drivers, I think 
> that a language driver for each variant above should be "plugable." Moreover, 
> we should provide one driver implementation for each -- simple GremlinServer 
> REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
>   gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
>   gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we 
> have to implement each {{g_V_out_repeatXasXaXX}} test case in 
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to 
> convert all those tests from Gremlin-Java to the respective host language? 
> However, even if we do that, we still have the problem of how to test the 
> returned results. 
> I think what we should test the returned results using the JVM. For instance, 
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a 
> massive headache. All we have to do is create a {{GraphProvider}} that uses 
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around 
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the 
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb   // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414260#comment-15414260
 ] 

ASF GitHub Bot commented on TINKERPOP-1278:
---

Github user leifurhauks commented on the issue:

https://github.com/apache/tinkerpop/pull/357
  
Added WIP to the title of the PR while I sort out some silly mistakes I 
made with the conflict resolution...


> Implement Gremlin-Python and general purpose language variant test 
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language 
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model 
> presented in 
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
>  Moreover, on every {{mvn clean install}}, the code for these variants is 
> generated.
> Given the desire to separate language variants from language drivers, I think 
> that a language driver for each variant above should be "plugable." Moreover, 
> we should provide one driver implementation for each -- simple GremlinServer 
> REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
>   gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
>   gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we 
> have to implement each {{g_V_out_repeatXasXaXX}} test case in 
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to 
> convert all those tests from Gremlin-Java to the respective host language? 
> However, even if we do that, we still have the problem of how to test the 
> returned results. 
> I think what we should test the returned results using the JVM. For instance, 
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a 
> massive headache. All we have to do is create a {{GraphProvider}} that uses 
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around 
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the 
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb   // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414198#comment-15414198
 ] 

ASF GitHub Bot commented on TINKERPOP-1278:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/357
  
I tried to merge this but there were two problem:

1.) the PR references old code and thus, lots of conflicts.
2.) graph_traversal and traversal are auto-generated and thus editing the 
.py does nothing.
3.) Jython complains in JythonScriptEngineSetup (tests don't pass)

If you can fix this PR accordingly, I'd be happy to merge.


> Implement Gremlin-Python and general purpose language variant test 
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language 
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model 
> presented in 
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
>  Moreover, on every {{mvn clean install}}, the code for these variants is 
> generated.
> Given the desire to separate language variants from language drivers, I think 
> that a language driver for each variant above should be "plugable." Moreover, 
> we should provide one driver implementation for each -- simple GremlinServer 
> REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
>   gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
>   gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we 
> have to implement each {{g_V_out_repeatXasXaXX}} test case in 
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to 
> convert all those tests from Gremlin-Java to the respective host language? 
> However, even if we do that, we still have the problem of how to test the 
> returned results. 
> I think what we should test the returned results using the JVM. For instance, 
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a 
> massive headache. All we have to do is create a {{GraphProvider}} that uses 
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around 
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the 
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb   // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414327#comment-15414327
 ] 

ASF GitHub Bot commented on TINKERPOP-1278:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/357


> Implement Gremlin-Python and general purpose language variant test 
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language 
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model 
> presented in 
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
>  Moreover, on every {{mvn clean install}}, the code for these variants is 
> generated.
> Given the desire to separate language variants from language drivers, I think 
> that a language driver for each variant above should be "plugable." Moreover, 
> we should provide one driver implementation for each -- simple GremlinServer 
> REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
>   gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
>   gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we 
> have to implement each {{g_V_out_repeatXasXaXX}} test case in 
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to 
> convert all those tests from Gremlin-Java to the respective host language? 
> However, even if we do that, we still have the problem of how to test the 
> returned results. 
> I think what we should test the returned results using the JVM. For instance, 
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a 
> massive headache. All we have to do is create a {{GraphProvider}} that uses 
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around 
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the 
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb   // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1063) TinkerGraph performance enhancements

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357049#comment-15357049
 ] 

ASF GitHub Bot commented on TINKERPOP-1063:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/342
  
Cool stuff. `Stream` is evil. It lurks throughout the codebase... Its 
funny, we were all gun ho for Java8, but we barely use it :(  VOTE +1.


> TinkerGraph performance enhancements
> 
>
> Key: TINKERPOP-1063
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1063
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: tinkergraph
>Affects Versions: 3.1.0-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.1.3
>
>
> Improve TinkerGraph performance in relation to the Ferma Benchmark which 
> shows a reasonably wide gap between TP2 and TP3.  We probably won't achieve 
> parity with Blueprints but it would be nice to carve away some time to lessen 
> the gap.
> https://github.com/Syncleus/Ferma-benchmark



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1349) RepeatUnrollStrategy should unroll loops while maintaining equivalent semantics.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357063#comment-15357063
 ] 

ASF GitHub Bot commented on TINKERPOP-1349:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/349


> RepeatUnrollStrategy should unroll loops while maintaining equivalent 
> semantics.
> 
>
> Key: TINKERPOP-1349
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1349
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.1
>
>
> Create {{RepeatUnrollStrategy}} that will unroll patterns such as:
> {code}
> repeat(out()).times(3)
> // ->
> out().barrier().out().barrier().out().barrier()
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1063) TinkerGraph performance enhancements

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356855#comment-15356855
 ] 

ASF GitHub Bot commented on TINKERPOP-1063:
---

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/342
  
VOTE: +1


> TinkerGraph performance enhancements
> 
>
> Key: TINKERPOP-1063
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1063
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: tinkergraph
>Affects Versions: 3.1.0-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.1.3
>
>
> Improve TinkerGraph performance in relation to the Ferma Benchmark which 
> shows a reasonably wide gap between TP2 and TP3.  We probably won't achieve 
> parity with Blueprints but it would be nice to carve away some time to lessen 
> the gap.
> https://github.com/Syncleus/Ferma-benchmark



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356821#comment-15356821
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user newkek commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
Yes that was introduced by the ce19704 (reference docs and Changelog)


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1341) UnshadedKryoAdapter fails to deserialize StarGraph when SparkConf sets spark.rdd.compress=true whereas GryoSerializer works

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357251#comment-15357251
 ] 

ASF GitHub Bot commented on TINKERPOP-1341:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/353
  
VOTE +1.


> UnshadedKryoAdapter fails to deserialize StarGraph when SparkConf sets 
> spark.rdd.compress=true whereas GryoSerializer works
> ---
>
> Key: TINKERPOP-1341
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1341
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.1, 3.3.0
>Reporter: Dylan Bethune-Waddell
>Priority: Minor
>
> When trying to bulk load a large dataset into Titan I was running into OOM 
> errors and decided to try tweaking some spark configuration settings - 
> although I am having trouble bulk loading with the new 
> GryoRegistrator/UnshadedKryo serialization shim stuff in master whereby a few 
> hundred tasks into the edge loading stage (stage 5) exceptions are thrown 
> complaining about the need to explicitly register CompactBuffer[].class with 
> Kryo, this approach with spark.rdd.compress=true fails a few hundred tasks 
> into the vertex loading stage (stage 1) of BulkLoaderVertexProgram. 
> GryoSerializer instead of KryoSerializer with GryoRegistrator does not fail 
> and successfully loads the data with this compression flag flipped on whereas 
> before I would just get OOM errors until eventually the job was set back so 
> far that it just failed. So it would seem it is desirable in some instances 
> to use this setting, and the new Serialization stuff seems to break it. Could 
> be a Spark upstream issue based on this open JIRA ticket 
> (https://issues.apache.org/jira/browse/SPARK-3630). Here is the exception 
> that is thrown with the middle bits cut out:
> com.esotericsoftware.kryo.KryoException: java.io.IOException: PARSING_ERROR(2)
> at com.esotericsoftware.kryo.io.Input.fill(Input.java:142)
> at com.esotericsoftware.kryo.io.Input.require(Input.java:169)
> at com.esotericsoftware.kryo.io.Input.readLong_slow(Input.java:715)
> at com.esotericsoftware.kryo.io.Input.readLong(Input.java:665)
> at 
> com.esotericsoftware.kryo.serializers.DefaultSerializers$LongSerializer.read(DefaultSerializers.java:113)
> at 
> com.esotericsoftware.kryo.serializers.DefaultSerializers$LongSerializer.read(DefaultSerializers.java:103)
> at com.esotericsoftware.kryo.Kryo.readClassAndObject(Kryo.java:729)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedKryoAdapter.readClassAndObject(UnshadedKryoAdapter.java:48)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedKryoAdapter.readClassAndObject(UnshadedKryoAdapter.java:30)
> at 
> org.apache.tinkerpop.gremlin.structure.util.star.StarGraphSerializer.readEdges(StarGraphSerializer.java:134)
> at 
> org.apache.tinkerpop.gremlin.structure.util.star.StarGraphSerializer.read(StarGraphSerializer.java:91)
> at 
> org.apache.tinkerpop.gremlin.structure.util.star.StarGraphSerializer.read(StarGraphSerializer.java:45)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedSerializerAdapter.read(UnshadedSerializerAdapter.java:55)
> at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:626)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedKryoAdapter.readObject(UnshadedKryoAdapter.java:42)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedKryoAdapter.readObject(UnshadedKryoAdapter.java:30)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.VertexWritableSerializer.read(VertexWritableSerializer.java:46)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.VertexWritableSerializer.read(VertexWritableSerializer.java:36)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedSerializerAdapter.read(UnshadedSerializerAdapter.java:55)
> at com.esotericsoftware.kryo.Kryo.readClassAndObject(Kryo.java:729)
> at 
> org.apache.spark.serializer.KryoDeserializationStream.readObject(KryoSerializer.scala:228)
>  and so on 
> .
> Caused by: java.io.IOException: PARSING_ERROR(2)
> at org.xerial.snappy.SnappyNative.throw_error(SnappyNative.java:84)
> at org.xerial.snappy.SnappyNative.uncompressedLength(Native Method)
> at org.xerial.snappy.Snappy.uncompressedLength(Snappy.java:594)
>

[jira] [Commented] (TINKERPOP-1341) UnshadedKryoAdapter fails to deserialize StarGraph when SparkConf sets spark.rdd.compress=true whereas GryoSerializer works

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357254#comment-15357254
 ] 

ASF GitHub Bot commented on TINKERPOP-1341:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/353
  
Crazy. I never new `void.class` existing in Java. ?!


> UnshadedKryoAdapter fails to deserialize StarGraph when SparkConf sets 
> spark.rdd.compress=true whereas GryoSerializer works
> ---
>
> Key: TINKERPOP-1341
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1341
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.1, 3.3.0
>Reporter: Dylan Bethune-Waddell
>Priority: Minor
>
> When trying to bulk load a large dataset into Titan I was running into OOM 
> errors and decided to try tweaking some spark configuration settings - 
> although I am having trouble bulk loading with the new 
> GryoRegistrator/UnshadedKryo serialization shim stuff in master whereby a few 
> hundred tasks into the edge loading stage (stage 5) exceptions are thrown 
> complaining about the need to explicitly register CompactBuffer[].class with 
> Kryo, this approach with spark.rdd.compress=true fails a few hundred tasks 
> into the vertex loading stage (stage 1) of BulkLoaderVertexProgram. 
> GryoSerializer instead of KryoSerializer with GryoRegistrator does not fail 
> and successfully loads the data with this compression flag flipped on whereas 
> before I would just get OOM errors until eventually the job was set back so 
> far that it just failed. So it would seem it is desirable in some instances 
> to use this setting, and the new Serialization stuff seems to break it. Could 
> be a Spark upstream issue based on this open JIRA ticket 
> (https://issues.apache.org/jira/browse/SPARK-3630). Here is the exception 
> that is thrown with the middle bits cut out:
> com.esotericsoftware.kryo.KryoException: java.io.IOException: PARSING_ERROR(2)
> at com.esotericsoftware.kryo.io.Input.fill(Input.java:142)
> at com.esotericsoftware.kryo.io.Input.require(Input.java:169)
> at com.esotericsoftware.kryo.io.Input.readLong_slow(Input.java:715)
> at com.esotericsoftware.kryo.io.Input.readLong(Input.java:665)
> at 
> com.esotericsoftware.kryo.serializers.DefaultSerializers$LongSerializer.read(DefaultSerializers.java:113)
> at 
> com.esotericsoftware.kryo.serializers.DefaultSerializers$LongSerializer.read(DefaultSerializers.java:103)
> at com.esotericsoftware.kryo.Kryo.readClassAndObject(Kryo.java:729)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedKryoAdapter.readClassAndObject(UnshadedKryoAdapter.java:48)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedKryoAdapter.readClassAndObject(UnshadedKryoAdapter.java:30)
> at 
> org.apache.tinkerpop.gremlin.structure.util.star.StarGraphSerializer.readEdges(StarGraphSerializer.java:134)
> at 
> org.apache.tinkerpop.gremlin.structure.util.star.StarGraphSerializer.read(StarGraphSerializer.java:91)
> at 
> org.apache.tinkerpop.gremlin.structure.util.star.StarGraphSerializer.read(StarGraphSerializer.java:45)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedSerializerAdapter.read(UnshadedSerializerAdapter.java:55)
> at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:626)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedKryoAdapter.readObject(UnshadedKryoAdapter.java:42)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedKryoAdapter.readObject(UnshadedKryoAdapter.java:30)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.VertexWritableSerializer.read(VertexWritableSerializer.java:46)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.VertexWritableSerializer.read(VertexWritableSerializer.java:36)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedSerializerAdapter.read(UnshadedSerializerAdapter.java:55)
> at com.esotericsoftware.kryo.Kryo.readClassAndObject(Kryo.java:729)
> at 
> org.apache.spark.serializer.KryoDeserializationStream.readObject(KryoSerializer.scala:228)
>  and so on 
> .
> Caused by: java.io.IOException: PARSING_ERROR(2)
> at org.xerial.snappy.SnappyNative.throw_error(SnappyNative.java:84)
> at org.xerial.snappy.SnappyNative.uncompressedLength(Native Method)
> at 

[jira] [Commented] (TINKERPOP-1320) GremlinGroovyScriptEngineFileSandboxTest throws error: URI is not hierarchical

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357466#comment-15357466
 ] 

ASF GitHub Bot commented on TINKERPOP-1320:
---

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/336
  
@spmallette I'll get this finished up before the weekend


> GremlinGroovyScriptEngineFileSandboxTest throws error: URI is not hierarchical
> --
>
> Key: TINKERPOP-1320
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1320
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> This is similar to TINKERPOP-1317. The differences here are
> * The {{TestHelper.generateTempFileFromResource()}} call to load the resource 
> is happening from the {{public static void init()}} method before a graph 
> instance is available.
> * A reference to {{GremlinGroovyScriptEngineFileSandboxTest.class}} is still 
> required to located the {{sandbox.yaml}} found in the {{gremlin-test.jar}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357479#comment-15357479
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user newkek commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
Re-conflicts with Changelog against master..


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1354) Include all static enum imports in request validation for bindings

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357505#comment-15357505
 ] 

ASF GitHub Bot commented on TINKERPOP-1354:
---

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/354

TINKERPOP-1354 Added more invalid binding keys to Gremlin Server validation

https://issues.apache.org/jira/browse/TINKERPOP-1354

These "invalid" keys are reserved terms for Gremlin Server as they are 
statically imported enums and shouldn't be used as binding keys. You get some 
less than easy to understand error messages if those keys are used. 

I would have CTR'd but wanted to see if anyone had other suggestions for 
additional validations at play. Also, this change is "breaking" in the sense 
that users who were somehow successfully using some of these newly reserved 
keys on previous versions (not fully sure if that was even possible) will have 
to update their code. I don't think this is a massive problem for someone to 
fix, so while "breaking" it doesn't seem massively detrimental and shouldn't be 
widely problematic.

Builds with `mvn clean install -DskipTests && mvn verify -pl gremlin-server 
-DskipIntegrationTests=false`

VOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1354

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/354.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #354


commit c37c3016bd05b3caeb09084f5469c606c439bfe5
Author: Stephen Mallette 
Date:   2016-06-30T17:07:44Z

Added more invalid binding keys to Gremlin Server OpProcessor validation.

These "invalid" keys are reserved terms for Gremlin Server as they are 
statically imported enums and shouldn't be used as binding keys. You get some 
less than easy to understand error messages if those keys are used.




> Include all static enum imports in request validation for bindings
> --
>
> Key: TINKERPOP-1354
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1354
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>  Labels: breaking
> Fix For: 3.1.3, 3.2.1
>
>
> Gremlin Server validates the bindings of incoming requests and returns an 
> error for any reserved terms. The list of reserved terms only includes {{T}} 
> but should also include others like {{Order}} and {{Scope}} so that users 
> don't inadvertently override them with a request binding. When that happens 
> Gremlin Server throws a not so easy to understand error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1352) Connection Pool doesn't always grow

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357601#comment-15357601
 ] 

ASF GitHub Bot commented on TINKERPOP-1352:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/352
  
hmm - you're right - i'm getting that now too. i wonder why i didn't see 
that yesterday. investigating now.


> Connection Pool doesn't always grow 
> 
>
> Key: TINKERPOP-1352
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1352
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.3, 3.2.1
>
>
> With certain configurations (that aren't terribly intuitive) of the driver, 
> the connection pool won't grow properly - this includes the default 
> configuration. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357513#comment-15357513
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
yeah - we tend to bump heads on master a little bit on the CHANGELOG - not 
a big deal - i can resolve that conflict when the time comes.


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1352) Connection Pool doesn't always grow

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357870#comment-15357870
 ] 

ASF GitHub Bot commented on TINKERPOP-1352:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/352
  
@robertdale i think i fixed the problem. i've been hunting that issue 
forever, but have never been able to witness it with any kind of consistent 
nature to unravel the problem. i guess my earlier changes in this branch 
allowed me to see semi-consistently (once every few runs) which was painful but 
good enough to get to the bottom of it. it would be great if you could try the 
build again - thanks for testing it out.


> Connection Pool doesn't always grow 
> 
>
> Key: TINKERPOP-1352
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1352
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.3, 3.2.1
>
>
> With certain configurations (that aren't terribly intuitive) of the driver, 
> the connection pool won't grow properly - this includes the default 
> configuration. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1354) Include all static enum imports in request validation for bindings

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357887#comment-15357887
 ] 

ASF GitHub Bot commented on TINKERPOP-1354:
---

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/354
  
BUILD SUCCESS


> Include all static enum imports in request validation for bindings
> --
>
> Key: TINKERPOP-1354
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1354
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>  Labels: breaking
> Fix For: 3.1.3, 3.2.1
>
>
> Gremlin Server validates the bindings of incoming requests and returns an 
> error for any reserved terms. The list of reserved terms only includes {{T}} 
> but should also include others like {{Order}} and {{Scope}} so that users 
> don't inadvertently override them with a request binding. When that happens 
> Gremlin Server throws a not so easy to understand error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358840#comment-15358840
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user spmallette commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/351#discussion_r69287612
  
--- Diff: 
tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/IoDataGenerationTest.java
 ---
@@ -275,4 +290,78 @@ else if (e.label().equals("writtenBy"))
 
GraphSONWriter.build().mapper(GraphSONMapper.build().embedTypes(true).create()).create().writeGraph(os4,
 g);
 os4.close();
 }
+
+@Test
+public void shouldWriteGratefulDeadGraphSONV2d0() throws IOException {
+final TinkerGraph g = TinkerGraph.open();
+final TinkerGraph readG = TinkerGraph.open();
+
+final GraphReader reader = GryoReader.build().create();
+try (final InputStream stream = 
AbstractGremlinTest.class.getResourceAsStream("/org/apache/tinkerpop/gremlin/structure/io/gryo/grateful-dead.kryo"))
 {
+reader.readGraph(stream, g);
+}
+final OutputStream os2 = new FileOutputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONWriter.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().writeGraph(os2,
 g);
+os2.close();
+
+final InputStream is = new FileInputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONReader.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().readGraph(is,
 readG);
+is.close();
+
+assertEquals(approximateGraphsCheck(g, readG), true);
+}
+
+/**
+ * Checks sequentially vertices and egdes of both graphs. Will check 
sequentially Vertex IDs, Vertex Properties IDs
+ * and values and classes. Then same for edges. To use when 
serializing a Graph and deserializing the supposedly
+ * same Graph.
+ */
+private boolean approximateGraphsCheck(Graph g1, Graph g2) {
--- End diff --

hmm - strange that never was a problem before. something must have changed 
(we haven't run with -Dio in a long long time) feel free to fix it in this 
branch. thanks


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358731#comment-15358731
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user newkek commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/351#discussion_r69276332
  
--- Diff: 
tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/IoDataGenerationTest.java
 ---
@@ -275,4 +290,78 @@ else if (e.label().equals("writtenBy"))
 
GraphSONWriter.build().mapper(GraphSONMapper.build().embedTypes(true).create()).create().writeGraph(os4,
 g);
 os4.close();
 }
+
+@Test
+public void shouldWriteGratefulDeadGraphSONV2d0() throws IOException {
+final TinkerGraph g = TinkerGraph.open();
+final TinkerGraph readG = TinkerGraph.open();
+
+final GraphReader reader = GryoReader.build().create();
+try (final InputStream stream = 
AbstractGremlinTest.class.getResourceAsStream("/org/apache/tinkerpop/gremlin/structure/io/gryo/grateful-dead.kryo"))
 {
+reader.readGraph(stream, g);
+}
+final OutputStream os2 = new FileOutputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONWriter.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().writeGraph(os2,
 g);
+os2.close();
+
+final InputStream is = new FileInputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONReader.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().readGraph(is,
 readG);
+is.close();
+
+assertEquals(approximateGraphsCheck(g, readG), true);
+}
+
+/**
+ * Checks sequentially vertices and egdes of both graphs. Will check 
sequentially Vertex IDs, Vertex Properties IDs
+ * and values and classes. Then same for edges. To use when 
serializing a Graph and deserializing the supposedly
+ * same Graph.
+ */
+private boolean approximateGraphsCheck(Graph g1, Graph g2) {
--- End diff --

Oh I think I see what you mean, I don't see them in the root's `data/` dir, 
I don't know why


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1352) Connection Pool doesn't always grow

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358838#comment-15358838
 ] 

ASF GitHub Bot commented on TINKERPOP-1352:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/352
  
Just pushed what I think is the final fixes for this issue. Note that this 
branch also contains the fix for 

https://issues.apache.org/jira/browse/TINKERPOP-1351

Please feel free to test/review/vote at this point. Thanks.


> Connection Pool doesn't always grow 
> 
>
> Key: TINKERPOP-1352
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1352
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.3, 3.2.1
>
>
> With certain configurations (that aren't terribly intuitive) of the driver, 
> the connection pool won't grow properly - this includes the default 
> configuration. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358847#comment-15358847
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user newkek commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/351#discussion_r69288319
  
--- Diff: 
tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/IoDataGenerationTest.java
 ---
@@ -275,4 +290,78 @@ else if (e.label().equals("writtenBy"))
 
GraphSONWriter.build().mapper(GraphSONMapper.build().embedTypes(true).create()).create().writeGraph(os4,
 g);
 os4.close();
 }
+
+@Test
+public void shouldWriteGratefulDeadGraphSONV2d0() throws IOException {
+final TinkerGraph g = TinkerGraph.open();
+final TinkerGraph readG = TinkerGraph.open();
+
+final GraphReader reader = GryoReader.build().create();
+try (final InputStream stream = 
AbstractGremlinTest.class.getResourceAsStream("/org/apache/tinkerpop/gremlin/structure/io/gryo/grateful-dead.kryo"))
 {
+reader.readGraph(stream, g);
+}
+final OutputStream os2 = new FileOutputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONWriter.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().writeGraph(os2,
 g);
+os2.close();
+
+final InputStream is = new FileInputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONReader.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().readGraph(is,
 readG);
+is.close();
+
+assertEquals(approximateGraphsCheck(g, readG), true);
+}
+
+/**
+ * Checks sequentially vertices and egdes of both graphs. Will check 
sequentially Vertex IDs, Vertex Properties IDs
+ * and values and classes. Then same for edges. To use when 
serializing a Graph and deserializing the supposedly
+ * same Graph.
+ */
+private boolean approximateGraphsCheck(Graph g1, Graph g2) {
--- End diff --

Apparently the TestHelper behaviour has changed in commit da2eb7e, but the 
pom wasn't changed with regards to that change.

Ok I'll change the pom as explained earlier


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358854#comment-15358854
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user newkek commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/351#discussion_r69288856
  
--- Diff: 
tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/IoDataGenerationTest.java
 ---
@@ -275,4 +290,78 @@ else if (e.label().equals("writtenBy"))
 
GraphSONWriter.build().mapper(GraphSONMapper.build().embedTypes(true).create()).create().writeGraph(os4,
 g);
 os4.close();
 }
+
+@Test
+public void shouldWriteGratefulDeadGraphSONV2d0() throws IOException {
+final TinkerGraph g = TinkerGraph.open();
+final TinkerGraph readG = TinkerGraph.open();
+
+final GraphReader reader = GryoReader.build().create();
+try (final InputStream stream = 
AbstractGremlinTest.class.getResourceAsStream("/org/apache/tinkerpop/gremlin/structure/io/gryo/grateful-dead.kryo"))
 {
+reader.readGraph(stream, g);
+}
+final OutputStream os2 = new FileOutputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONWriter.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().writeGraph(os2,
 g);
+os2.close();
+
+final InputStream is = new FileInputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONReader.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().readGraph(is,
 readG);
+is.close();
+
+assertEquals(approximateGraphsCheck(g, readG), true);
+}
+
+/**
+ * Checks sequentially vertices and egdes of both graphs. Will check 
sequentially Vertex IDs, Vertex Properties IDs
+ * and values and classes. Then same for edges. To use when 
serializing a Graph and deserializing the supposedly
+ * same Graph.
+ */
+private boolean approximateGraphsCheck(Graph g1, Graph g2) {
--- End diff --

So, since now the build creates the new v2d0 graphs, and it seems like the 
other ones are pushed in the repo, should I push the new ones too? Also, it 
seems that the already pushed ones have modifications. Should I push all of as 
well ? Here's the diff : 
https://gist.github.com/newkek/4e0488268f9bb78e0d3597821ae6b357


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1341) UnshadedKryoAdapter fails to deserialize StarGraph when SparkConf sets spark.rdd.compress=true whereas GryoSerializer works

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358859#comment-15358859
 ] 

ASF GitHub Bot commented on TINKERPOP-1341:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/353
  
VOTE +1


> UnshadedKryoAdapter fails to deserialize StarGraph when SparkConf sets 
> spark.rdd.compress=true whereas GryoSerializer works
> ---
>
> Key: TINKERPOP-1341
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1341
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.1, 3.3.0
>Reporter: Dylan Bethune-Waddell
>Priority: Minor
>
> When trying to bulk load a large dataset into Titan I was running into OOM 
> errors and decided to try tweaking some spark configuration settings - 
> although I am having trouble bulk loading with the new 
> GryoRegistrator/UnshadedKryo serialization shim stuff in master whereby a few 
> hundred tasks into the edge loading stage (stage 5) exceptions are thrown 
> complaining about the need to explicitly register CompactBuffer[].class with 
> Kryo, this approach with spark.rdd.compress=true fails a few hundred tasks 
> into the vertex loading stage (stage 1) of BulkLoaderVertexProgram. 
> GryoSerializer instead of KryoSerializer with GryoRegistrator does not fail 
> and successfully loads the data with this compression flag flipped on whereas 
> before I would just get OOM errors until eventually the job was set back so 
> far that it just failed. So it would seem it is desirable in some instances 
> to use this setting, and the new Serialization stuff seems to break it. Could 
> be a Spark upstream issue based on this open JIRA ticket 
> (https://issues.apache.org/jira/browse/SPARK-3630). Here is the exception 
> that is thrown with the middle bits cut out:
> com.esotericsoftware.kryo.KryoException: java.io.IOException: PARSING_ERROR(2)
> at com.esotericsoftware.kryo.io.Input.fill(Input.java:142)
> at com.esotericsoftware.kryo.io.Input.require(Input.java:169)
> at com.esotericsoftware.kryo.io.Input.readLong_slow(Input.java:715)
> at com.esotericsoftware.kryo.io.Input.readLong(Input.java:665)
> at 
> com.esotericsoftware.kryo.serializers.DefaultSerializers$LongSerializer.read(DefaultSerializers.java:113)
> at 
> com.esotericsoftware.kryo.serializers.DefaultSerializers$LongSerializer.read(DefaultSerializers.java:103)
> at com.esotericsoftware.kryo.Kryo.readClassAndObject(Kryo.java:729)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedKryoAdapter.readClassAndObject(UnshadedKryoAdapter.java:48)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedKryoAdapter.readClassAndObject(UnshadedKryoAdapter.java:30)
> at 
> org.apache.tinkerpop.gremlin.structure.util.star.StarGraphSerializer.readEdges(StarGraphSerializer.java:134)
> at 
> org.apache.tinkerpop.gremlin.structure.util.star.StarGraphSerializer.read(StarGraphSerializer.java:91)
> at 
> org.apache.tinkerpop.gremlin.structure.util.star.StarGraphSerializer.read(StarGraphSerializer.java:45)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedSerializerAdapter.read(UnshadedSerializerAdapter.java:55)
> at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:626)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedKryoAdapter.readObject(UnshadedKryoAdapter.java:42)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedKryoAdapter.readObject(UnshadedKryoAdapter.java:30)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.VertexWritableSerializer.read(VertexWritableSerializer.java:46)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.VertexWritableSerializer.read(VertexWritableSerializer.java:36)
> at 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.kryoshim.unshaded.UnshadedSerializerAdapter.read(UnshadedSerializerAdapter.java:55)
> at com.esotericsoftware.kryo.Kryo.readClassAndObject(Kryo.java:729)
> at 
> org.apache.spark.serializer.KryoDeserializationStream.readObject(KryoSerializer.scala:228)
>  and so on 
> .
> Caused by: java.io.IOException: PARSING_ERROR(2)
> at org.xerial.snappy.SnappyNative.throw_error(SnappyNative.java:84)
> at org.xerial.snappy.SnappyNative.uncompressedLength(Native Method)
> at org.xerial.snappy.Snappy.uncompressedLength(Snappy.java:594)
>

[jira] [Commented] (TINKERPOP-1352) Connection Pool doesn't always grow

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358067#comment-15358067
 ] 

ASF GitHub Bot commented on TINKERPOP-1352:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/352
  
Just pushed a fix. It was more a problem with the configuration of the 
client in the test than a bug. I think the recent fixes in this branch made 
some things suddenly "work" and it caused these side cases to start squeezing 
out problems. I've had several successful runs at this point with no troubles 
so I think that both tests might be solid now.

While I was in the debugger, I noticed one final thing that I don't really 
like that I'd like to resolved, so reviewers may want to hang on to their votes 
for a little bit longer for this one.


> Connection Pool doesn't always grow 
> 
>
> Key: TINKERPOP-1352
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1352
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.3, 3.2.1
>
>
> With certain configurations (that aren't terribly intuitive) of the driver, 
> the connection pool won't grow properly - this includes the default 
> configuration. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358725#comment-15358725
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user newkek commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/351#discussion_r69275891
  
--- Diff: 
tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/IoDataGenerationTest.java
 ---
@@ -275,4 +290,78 @@ else if (e.label().equals("writtenBy"))
 
GraphSONWriter.build().mapper(GraphSONMapper.build().embedTypes(true).create()).create().writeGraph(os4,
 g);
 os4.close();
 }
+
+@Test
+public void shouldWriteGratefulDeadGraphSONV2d0() throws IOException {
+final TinkerGraph g = TinkerGraph.open();
+final TinkerGraph readG = TinkerGraph.open();
+
+final GraphReader reader = GryoReader.build().create();
+try (final InputStream stream = 
AbstractGremlinTest.class.getResourceAsStream("/org/apache/tinkerpop/gremlin/structure/io/gryo/grateful-dead.kryo"))
 {
+reader.readGraph(stream, g);
+}
+final OutputStream os2 = new FileOutputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONWriter.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().writeGraph(os2,
 g);
+os2.close();
+
+final InputStream is = new FileInputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONReader.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().readGraph(is,
 readG);
+is.close();
+
+assertEquals(approximateGraphsCheck(g, readG), true);
+}
+
+/**
+ * Checks sequentially vertices and egdes of both graphs. Will check 
sequentially Vertex IDs, Vertex Properties IDs
+ * and values and classes. Then same for edges. To use when 
serializing a Graph and deserializing the supposedly
+ * same Graph.
+ */
+private boolean approximateGraphsCheck(Graph g1, Graph g2) {
--- End diff --

Where are they supposed to be located ? I see them in the 
`tinkergraph-gremlin/target/test-case-data/TinkerGraphTest/tinkerpop-io/`. 
Should they be somewhere else?


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358784#comment-15358784
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user newkek commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/351#discussion_r69283048
  
--- Diff: 
tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/IoDataGenerationTest.java
 ---
@@ -275,4 +290,78 @@ else if (e.label().equals("writtenBy"))
 
GraphSONWriter.build().mapper(GraphSONMapper.build().embedTypes(true).create()).create().writeGraph(os4,
 g);
 os4.close();
 }
+
+@Test
+public void shouldWriteGratefulDeadGraphSONV2d0() throws IOException {
+final TinkerGraph g = TinkerGraph.open();
+final TinkerGraph readG = TinkerGraph.open();
+
+final GraphReader reader = GryoReader.build().create();
+try (final InputStream stream = 
AbstractGremlinTest.class.getResourceAsStream("/org/apache/tinkerpop/gremlin/structure/io/gryo/grateful-dead.kryo"))
 {
+reader.readGraph(stream, g);
+}
+final OutputStream os2 = new FileOutputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONWriter.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().writeGraph(os2,
 g);
+os2.close();
+
+final InputStream is = new FileInputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONReader.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().readGraph(is,
 readG);
+is.close();
+
+assertEquals(approximateGraphsCheck(g, readG), true);
+}
+
+/**
+ * Checks sequentially vertices and egdes of both graphs. Will check 
sequentially Vertex IDs, Vertex Properties IDs
+ * and values and classes. Then same for edges. To use when 
serializing a Graph and deserializing the supposedly
+ * same Graph.
+ */
+private boolean approximateGraphsCheck(Graph g1, Graph g2) {
--- End diff --

Ah, looking at the pom, I'm getting this warning during the build : 

```
[INFO] --- maven-resources-plugin:2.6:copy-resources 
(copy-graphson-from-tmp-to-resources) @ tinkergraph-gremlin ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/Users/kevingallardo/Documents/workspace/newkek-incubator-tinkerpop/tinkergraph-gremlin/target/tinkerpop-io
```
Seems like the pom is going to search for the ressources in 
`${project.build.directory}/tinkerpop-io` and 
`${project.build.directory}` is defined as 
`${basedir}/target`.
But the `tempPath` in IoDataGenerationTest` is `tempPath = 
TestHelper.makeTestDataPath(TinkerGraphTest.class, "tinkerpop-io").getPath() + 
File.separator;`

If I change the pom to search in the right directory : 
`${project.build.directory}/test-case-data/TinkerGraphTest/tinkerpop-io`,
 it works.


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358728#comment-15358728
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user newkek commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/351#discussion_r69276176
  
--- Diff: 
tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/IoDataGenerationTest.java
 ---
@@ -275,4 +290,78 @@ else if (e.label().equals("writtenBy"))
 
GraphSONWriter.build().mapper(GraphSONMapper.build().embedTypes(true).create()).create().writeGraph(os4,
 g);
 os4.close();
 }
+
+@Test
+public void shouldWriteGratefulDeadGraphSONV2d0() throws IOException {
+final TinkerGraph g = TinkerGraph.open();
+final TinkerGraph readG = TinkerGraph.open();
+
+final GraphReader reader = GryoReader.build().create();
+try (final InputStream stream = 
AbstractGremlinTest.class.getResourceAsStream("/org/apache/tinkerpop/gremlin/structure/io/gryo/grateful-dead.kryo"))
 {
+reader.readGraph(stream, g);
+}
+final OutputStream os2 = new FileOutputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONWriter.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().writeGraph(os2,
 g);
+os2.close();
+
+final InputStream is = new FileInputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONReader.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().readGraph(is,
 readG);
+is.close();
+
+assertEquals(approximateGraphsCheck(g, readG), true);
+}
+
+/**
+ * Checks sequentially vertices and egdes of both graphs. Will check 
sequentially Vertex IDs, Vertex Properties IDs
+ * and values and classes. Then same for edges. To use when 
serializing a Graph and deserializing the supposedly
+ * same Graph.
+ */
+private boolean approximateGraphsCheck(Graph g1, Graph g2) {
--- End diff --

https://gist.github.com/newkek/643c907e54e93ab36594295281c3e4e6


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1352) Connection Pool doesn't always grow

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15359064#comment-15359064
 ] 

ASF GitHub Bot commented on TINKERPOP-1352:
---

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/352
  
5 consecutive passes


> Connection Pool doesn't always grow 
> 
>
> Key: TINKERPOP-1352
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1352
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Critical
> Fix For: 3.1.3, 3.2.1
>
>
> With certain configurations (that aren't terribly intuitive) of the driver, 
> the connection pool won't grow properly - this includes the default 
> configuration. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15355252#comment-15355252
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user newkek commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
> tests are failing

Ah I changed something quickly this morning and did not run again those 
tests. Will correct that.
Ok for the docs, will do.


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15355295#comment-15355295
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user newkek commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/351#discussion_r68951122
  
--- Diff: 
gremlin-driver/src/test/java/org/apache/tinkerpop/gremlin/driver/ser/GraphSONMessageSerializerV2d0Test.java
 ---
@@ -0,0 +1,474 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.tinkerpop.gremlin.driver.ser;
+
+import org.apache.tinkerpop.gremlin.driver.message.RequestMessage;
+import org.apache.tinkerpop.gremlin.driver.message.ResponseMessage;
+import org.apache.tinkerpop.gremlin.driver.message.ResponseStatusCode;
+import 
org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversalSource;
+import org.apache.tinkerpop.gremlin.process.traversal.step.util.Tree;
+import org.apache.tinkerpop.gremlin.structure.*;
+import org.apache.tinkerpop.gremlin.structure.io.AbstractIoRegistry;
+import org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONIo;
+import org.apache.tinkerpop.gremlin.structure.io.graphson.GraphSONTokens;
+import org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerFactory;
+import org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerGraph;
+import org.apache.tinkerpop.gremlin.util.iterator.IteratorUtils;
+import org.apache.tinkerpop.shaded.jackson.core.JsonGenerationException;
+import org.apache.tinkerpop.shaded.jackson.core.JsonGenerator;
+import org.apache.tinkerpop.shaded.jackson.databind.JsonNode;
+import org.apache.tinkerpop.shaded.jackson.databind.ObjectMapper;
+import org.apache.tinkerpop.shaded.jackson.databind.SerializerProvider;
+import org.apache.tinkerpop.shaded.jackson.databind.module.SimpleModule;
+import org.apache.tinkerpop.shaded.jackson.databind.node.NullNode;
+import org.apache.tinkerpop.shaded.jackson.databind.ser.std.StdSerializer;
+import org.apache.tinkerpop.shaded.jackson.databind.util.StdDateFormat;
+import org.junit.Test;
+
+import java.awt.*;
+import java.io.IOException;
+import java.util.*;
+
+import static org.hamcrest.MatcherAssert.assertThat;
+import static org.hamcrest.core.Is.is;
+import static org.junit.Assert.*;
+
+/**
+ * These tests focus on message serialization and not "result" 
serialization as test specific to results (e.g.
+ * vertices, edges, annotated values, etc.) are handled in the IO packages.
+ *
+ * @author Stephen Mallette (http://stephen.genoprime.com)
+ */
+public class GraphSONMessageSerializerV2d0Test {
--- End diff --

They are not all exactly the same, because some of these inspect the 
generated JSON payload manually (`shouldSerializeEdge()`) and since the format 
is different, and that types are introduced now, they don't get the expected 
property at the right place. [see 
here](https://github.com/apache/tinkerpop/pull/351/files#diff-c199205c0fbd8f1e71e0681fdd786555R230)
 (l.230) since the payload contains the type, we have to go in the Array's 
second element to get the value.


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15355048#comment-15355048
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

GitHub user newkek opened a pull request:

https://github.com/apache/tinkerpop/pull/351

TINKERPOP-1274: GraphSON 2.0.

https://issues.apache.org/jira/browse/TINKERPOP-1274

# Summary of the changes : 

Implementation of a format for value types serialization which is uniform 
and not Java centric. As a reminder the new format is as follows : 
- A value not typed : `value`
- A value typed : `[{"@class":"typeName"}, value]`

The content of `value` can be either a simple value, or a more complex 
structure. The type prefix allows to call the right _Deserializer_ to 
deserialize the `value` whatever its content is.

The default's GraphSON's 2.0 format will include types for every `value` 
that is not a JSON native type 
(`String/int/double/null/boolean/Map/Collection`) - called `PARTIAL_TYPES`. 
This allows to significantly reduce the size of the JSON payload where those 
aren't needed by the Jackson library.

GraphSON serialization _without_ types is not affected. To enable it, need 
to use `NO_TYPES`.

## Quick walkthrough for the review

There are new components involved in the ser/de process that are extended 
from the Jackson library :
- _TypeIdResolver_ : performs the conversion of a object's `Class` -> 
`typeID`, and from a `typeID` -> `Class`.

- _TypeResolverBuilder_ : creates a _TypeIdResolver_ and instantiates a 
_TypeDeserializer_ or _TypeSerializer_ with the _TypeIdResolver_ as a param.

- _TypeSerializer_ : writes the prefix and suffix for a typeID. The 
_TypeSerializer_ is provided to the _Serializers_ and handles the type 
serialization that respects the format put in place.

- _TypeDeserializer_ : is called before the deserializers are called. Its 
role is to detect a type, and call the right _Deserializer_ to deserialize the 
value.

Most of the serializers already existing for Graph had to be modified, 
because most of them were *manually hardcoding* types without calling the 
_TypeSerializer_ and hence, those were not respecting the format. Now all 
Serializers respect the format because they call the _TypeSerializer_ given in 
parameter. I followed the frame put in place by @spmallette to implement those 
new serializers (prefixed with `V2d0`) without breaking existing clients code.

In _TypeDeserializer_, `baseType` represents the class given in parameter 
by the user for the ser/de. If the user calls 
`mapper.readValueAsString(jsonString, UUID.class)` the `baseType` in 
_TypeDeserializer_ will be a _JavaType_ (which is the Jackson's custom class 
for Java classes) that represents a _UUID_ class. The *wildcard* in our 
deserialization mechanism is `Object.class`. 

The deserialization path is as follow : 
- _TypeDeserializer_ is called only for non simple JSON values (non 
`String/int/double/null/boolean`).
- When called, if a type is detected, the _TypeDeserializer_ will read the 
typeID, convert it to a JavaType (thanks to the _TypeIdResolver_), check that 
the `baseType` is the same than what was read in the payload (only if 
`baseType` is not the *wildcard*), and call the `deserialize()` method of the 
_JsonDeserializer_ registered for that type.
- If a type is not detected, detect Maps or Arrays and call appropriate 
Deserializer.

## Some results 

GraphSON 2.0 shows a significant reduction of the payload's size for typed 
serialization. And the consequence in performance is that since there's less to 
process, the ser/de is faster. Results show a reduction of at least 50% in the 
payload's size and evolving linearly (the bigger the payload the bigger the 
difference) : 

```
➜  ls -lh 
tinkergraph-gremlin/target/test-case-data/TinkerGraphTest/tinkerpop-io/
-rw-r--r--  1 kevingallardo  staff   890K 28 Jun 21:50 
grateful-dead-V2d0-typed.json
-rw-r--r--  1 kevingallardo  staff   1.9M 28 Jun 21:50 
grateful-dead-typed.json
-rw-r--r--  1 kevingallardo  staff   851K 28 Jun 21:50 grateful-dead.json
-rw-r--r--  1 kevingallardo  staff   1.5K 28 Jun 21:50 
tinkerpop-classic-V2d0-typed.json
-rw-r--r--  1 kevingallardo  staff   3.6K 28 Jun 21:50 
tinkerpop-classic-typed.json
-rw-r--r--  1 kevingallardo  staff   1.3K 28 Jun 21:50 
tinkerpop-classic.json
```

## Tests

Tests cover the same functionalities covered by GraphSON 1.0 typed, plus 
additional features brought by GraphSON 2.0. 

## Tradeoffs

- Some tricks were implemented in order to provide the types without 
packages names. Since Java does not provide a way to search a class by its 
simple name, the `TypeIdResolver` has to have an index that it can refer to, 

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15355071#comment-15355071
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user spmallette commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/351#discussion_r68931920
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONIo.java
 ---
@@ -22,11 +22,7 @@
 import org.apache.tinkerpop.gremlin.structure.io.Io;
 import org.apache.tinkerpop.gremlin.structure.io.IoRegistry;
 
-import java.io.FileInputStream;
-import java.io.FileOutputStream;
-import java.io.IOException;
-import java.io.InputStream;
-import java.io.OutputStream;
+import java.io.*;
--- End diff --

sorry @newkek but your IDE introduced wildcards to our imports which isn't 
our code style. could you please fix those?


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1349) RepeatUnrollStrategy should unroll loops while maintaining equivalent semantics.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356315#comment-15356315
 ] 

ASF GitHub Bot commented on TINKERPOP-1349:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/349
  
All tests pass with `docker/build.sh -t -n -i`

VOTE +1


> RepeatUnrollStrategy should unroll loops while maintaining equivalent 
> semantics.
> 
>
> Key: TINKERPOP-1349
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1349
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.0-incubating
>
>
> Create {{RepeatUnrollStrategy}} that will unroll patterns such as:
> {code}
> repeat(out()).times(3)
> // ->
> out().barrier().out().barrier().out().barrier()
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15359292#comment-15359292
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
I thought that java integer would be implied. I believe that if we wrote a 
java short for example it would type to a "Short" then you would know what kind 
of number it is. 

We purposely went away from the fully qualified class name which really 
doesn't mean much to non-JVM languages in favor of the more brief and less 
scary simple name - I thought we had decided that a smaller byte size for the 
network outweighed the downside of being less specific about the type. no?

> I would also like to point out that this format 
[{"@class":"java.lang.Integer"}, 1] can be a pain in systems that do not 
necessarily order lists.

I seem to remember that we discussed that before but don't remember the 
outcome - @newkek do you remember what was said?


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15359255#comment-15359255
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user PommeVerte commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
Hey guys,

I've been super busy lately but I definitely plan on diving deep into this 
PR over the weekend. One quick remark though.

1. Even the JSON supported types are not prone to lossiness in multi 
language settings. They should also be typed.
2. In a multi language setting, having type names without their java 
classes is not helpful. 

I can illustrate both of these points with the following JSON : `{"id":1}`
The client assumes `id` is `int` but what exactly is an int? is it `16bit`, 
`32bit`, or `64bit`? Languages will have their own definition here. Actually 
some languages will even have different values of `int` depending on how they 
were compiled. 
Changing it to `{"id":[{"@class":"Integer"}, 1]}` is not helpful in this 
case either. However the following is explicit and is something you can work 
with: `{"id":[{"@class":"java.lang.Integer"}, 1]}`. It's immediately 
identifiable and well documented. The client knows this is a 32bit Int and can 
work accordingly. Without this you would have to go through documentation or 
code to figure out what you were dealing with. 

In conclusion:

1. Thinking about it some more it's possible that Integer is the only 
special case that would need typing in the json supported types. I'll give it 
some more though. We could possibly have a "verbose" option for those who 
require typing of everything.
2. Type names should refer to the java class. This also seems to make sense 
when dealing with custom objects.


PS: I would also like to point out that this format 
`[{"@class":"java.lang.Integer"}, 1]` can be a pain in systems that do not 
necessarily order lists. With these systems you need to check that your list 
has two elements, that one is a map, and that the map contains a `@class` key. 
Costly operation.
Perhaps `{"@class":"java.lang.Integer", "value": 1}` is a better option. 


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15359121#comment-15359121
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user spmallette commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/351#discussion_r69315539
  
--- Diff: 
tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/IoDataGenerationTest.java
 ---
@@ -275,4 +290,78 @@ else if (e.label().equals("writtenBy"))
 
GraphSONWriter.build().mapper(GraphSONMapper.build().embedTypes(true).create()).create().writeGraph(os4,
 g);
 os4.close();
 }
+
+@Test
+public void shouldWriteGratefulDeadGraphSONV2d0() throws IOException {
+final TinkerGraph g = TinkerGraph.open();
+final TinkerGraph readG = TinkerGraph.open();
+
+final GraphReader reader = GryoReader.build().create();
+try (final InputStream stream = 
AbstractGremlinTest.class.getResourceAsStream("/org/apache/tinkerpop/gremlin/structure/io/gryo/grateful-dead.kryo"))
 {
+reader.readGraph(stream, g);
+}
+final OutputStream os2 = new FileOutputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONWriter.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().writeGraph(os2,
 g);
+os2.close();
+
+final InputStream is = new FileInputStream(tempPath + 
"grateful-dead-V2d0-typed.json");
+
GraphSONReader.build().mapper(GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create()).create().readGraph(is,
 readG);
+is.close();
+
+assertEquals(approximateGraphsCheck(g, readG), true);
+}
+
+/**
+ * Checks sequentially vertices and egdes of both graphs. Will check 
sequentially Vertex IDs, Vertex Properties IDs
+ * and values and classes. Then same for edges. To use when 
serializing a Graph and deserializing the supposedly
+ * same Graph.
+ */
+private boolean approximateGraphsCheck(Graph g1, Graph g2) {
--- End diff --

If you re-run the tests after you generate and they all pass, i think we 
should probably be safe.


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15359364#comment-15359364
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user newkek commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
> I thought that java integer would be implied.

Yes with the current PR serializing an Integer will result in no type 
added. Serializing a Long or a Short will result in an explicit type added. To 
be very explicit, in JSON everything is Doubles and Longs, it does that because 
it's the bigger container format that contains the others less precise ones. 
Jackson however, considers that when an Integer is to be serialized, there is 
no need for an explicit type because the precision will be kept since for JSON 
it's in a Long. When it comes to serializing a Long, still no precision loss 
but the format explicitly indicates to the Deserializer that what has been 
serialized initially was a Long. So everything is as defined as if the Integer 
was typed, because by default the reader assumes everything's an Integer, and 
if not there will be a type to specify what it is. However we have save a large 
payload size by not typing the integer. Same concept for Float VS Double, for 
JSON everything is a Double, if a value is a Float, it will be typed, if not, 
by default it's a Float.

So as I said in the description I think the outcome of the mail 
conversation was to not type Simple values. Mostly because we're not sure if 
this is going to be useful or not. However, adding those types in the future, 
for Simple values, can be very easily done and I've left detailed comments in 
the `TypeSerializer` on how to add them when we deem it necessary. Also, adding 
them would not break existing code since the format would be the same, it's 
just that _every_ value would follow the format for typed values. Since there's 
no possibility to mix-up for the Numeric values as explained above with the 
Shorts and Longs and etc... I still think we should wait somebody explicitly 
requires it.

> Perhaps {"@class":"java.lang.Integer", "value": 1} is a better option.

As I see it for how I implemented the TypeDeserializer, it acts as a meta 
deserializer that will read the raw text JSON sequentially, so there's no 
chance there can be a mixup in the order, it does not deserialize the whole 
structure and creates a `List>` object. Same for the TypeSerializer, it 
does not create a Java `List` object to write the type, but it writes directly 
in JSON "write a start_array token, write a start_map token, write a property 
name, write a text field (the type name), write a end_array token, etc" so same 
thing, there is no chance there can be a mix up in the order.
I don't know what it could look like for parsers of other languages, but it 
would seem like doing something else than that would be quite inefficient in 
terms of performance because it would that for every typed value you would 
instantiate a `new List>` just to read a simple value. Does that makes 
sense ?


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15360094#comment-15360094
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
I hope you guys figured it all out yesterday.I didn't follow all the 
comments, but started a `docker/build.sh -t -i -n` over-night job. It 
succeeded, thus

VOTE: +1


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15359614#comment-15359614
 ] 

ASF GitHub Bot commented on TINKERPOP-1274:
---

Github user newkek commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
@spmallette yes, maybe some code will help explain.

```
ObjectMapper mapper = 
GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create().createMapper();
Map map = new HashMap<>();
map.put("helo", 2);


String s = mapper.writeValueAsString(map);

// prints 's = {"helo":2}'
System.out.println("s = " + s);

Map read = mapper.readValue(s, Map.class);

// prints 'read.get("helo") = class java.lang.Integer'
System.out.println("read.get(\"helo\") = " + 
read.get("helo").getClass());

Map map3 = new HashMap<>();
map3.put("helo", 2L);


String s2 = mapper.writeValueAsString(map3);

// prints 's2 = {"helo":[{"@class":"Long"},2]}'
System.out.println("s2 = " + s2);

Map read2 = mapper.readValue(s2, Map.class);

// prints 'read2.get("helo") = class java.lang.Long'
System.out.println("read2.get(\"helo\") = " + 
read2.get("helo").getClass());
```

> number with decimal and no type = Java Float

Almost, by default decimals are Double, not Floats.


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)