date:20180116


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

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

Github user PBGraff commented on the issue:

https://github.com/apache/tinkerpop/pull/777
  
I don't have an environment for testing with Spark right now, so I was 
unable to run those tests. They're failing because for the test I added I want 
to create my own graph and add two vertices and two edges to it (see 
`runTest(Direction)` at line 2665 of `GraphComputerTest.java`). Is there a 
better way to do this that will be acceptable for Spark where it seems the 
graph is immutable? I was trying to not have to create another 
GraphML/GraphSON/Gryo graph to be stored.


> TinkerGraph VertexProgram message passing doesn't work properly when using 
> Direction.BOTH
> -
>
> Key: TINKERPOP-1862
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1862
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process, tinkergraph
>Affects Versions: 3.2.7
>Reporter: Philip Graff
>Priority: Major
>
> I think the messages are being sent properly in TinkerMessenger, but when I 
> call messenger.receiveMessages(), the vertex is getting messages from the 
> outVertex of their edges regardless of the edge direction. This is due to 
> line 71 of TinkerMessenger (linked below) which calls 
> Edge.vertices(direction).next(), thus getting the first result out of the 
> Vertex iterator. For IN or OUT, this isn't a problem. But for BOTH, following 
> line 124 of TinkerEdge (linked below), the outVertex is always returned 
> first. TinkerMessenger needs to be modified to return the correct vertex (I 
> think it's the one that != this.vertex).
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/process/computer/TinkerMessenger.java#L71
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerEdge.java#L124



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (TINKERPOP-1872) Apply edgeFunction in SparkMessenger

2018-01-16 Thread stephen mallette (JIRA)

stephen mallette created TINKERPOP-1872:
---

 Summary: Apply edgeFunction in SparkMessenger
 Key: TINKERPOP-1872
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1872
 Project: TinkerPop
  Issue Type: Bug
  Components: hadoop
Affects Versions: 3.2.7
Reporter: stephen mallette


It seem the edgeFunction defined in Local MessageScope will not be applied 
anywhere when you are using SparkGraphComputer.  It will cause a difference in 
result with what you will have when you are using TinkerGraphComputer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1867) union() can produce extra traversers


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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/775
  
I was hoping I could come up with some other form of testing for this 
change, but I can't seem to think of anything...

VOTE +1 (pending changelog entry)


> union() can produce extra traversers 
> -
>
> Key: TINKERPOP-1867
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1867
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Major
>
> Hard to say where this bug is coming from but basically the most simple 
> representation is:
> {code}
> gremlin> g.V(1,2).local(__.union(__.constant(1).count()))
> ==>1
> ==>0
> ==>1
> {code}
> Similar problems occur with {{sum()}} and other reducing barriers when used 
> in this context.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #775: TINKERPOP-1867 union() can produce extra traversers

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/775
  
I was hoping I could come up with some other form of testing for this 
change, but I can't seem to think of anything...

VOTE +1 (pending changelog entry)


---

[jira] [Commented] (TINKERPOP-1868) Support inject source step in Gremlin.Net


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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/776
  
ah - ok. i get what is happening now. thanks for clarifying. in that case:

VOTE +1


> Support inject source step in Gremlin.Net
> -
>
> Key: TINKERPOP-1868
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1868
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Priority: Minor
>
> {{GraphTraversalSource}} has no {{Inject}} step in Gremlin.Net because it's 
> explicitly excluded in the GLV generation:
> {code}
> "sourceSpawnMethods": GraphTraversalSource.getMethods(). // SPAWN STEPS
> findAll { GraphTraversal.class.equals(it.returnType) 
> && !it.name.equals('inject')}.
> // ...
> {code}
> I don't know why {{inject}} is explicitly excluded here, but there should be 
> an implementation in {{GraphTraversalSource}} as the other GLVs also have 
> this step.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #776: TINKERPOP-1868 Gremlin.Net: Add Inject step to GraphTr...

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/776
  
ah - ok. i get what is happening now. thanks for clarifying. in that case:

VOTE +1


---

[GitHub] tinkerpop issue #780: improve performace by not handling excepptions

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/780
  
I think this could be re-targetted at the tp32 branch - is there any reason 
not to @artem-aliev ?


---

[GitHub] tinkerpop issue #776: TINKERPOP-1868 Gremlin.Net: Add Inject step to GraphTr...

2018-01-16 Thread FlorianHockmann

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/776
  
I don't think that it is a breaking change as it only prevents users from 
sending traversals with invalid arguments for the `inject` step to the server 
which should cause a runtime error on the server side at the moment. With this 
change, this runtime error would now be a compile time error.


---

[jira] [Commented] (TINKERPOP-1868) Support inject source step in Gremlin.Net


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

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

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/776
  
I don't think that it is a breaking change as it only prevents users from 
sending traversals with invalid arguments for the `inject` step to the server 
which should cause a runtime error on the server side at the moment. With this 
change, this runtime error would now be a compile time error.


> Support inject source step in Gremlin.Net
> -
>
> Key: TINKERPOP-1868
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1868
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Priority: Minor
>
> {{GraphTraversalSource}} has no {{Inject}} step in Gremlin.Net because it's 
> explicitly excluded in the GLV generation:
> {code}
> "sourceSpawnMethods": GraphTraversalSource.getMethods(). // SPAWN STEPS
> findAll { GraphTraversal.class.equals(it.returnType) 
> && !it.name.equals('inject')}.
> // ...
> {code}
> I don't know why {{inject}} is explicitly excluded here, but there should be 
> an implementation in {{GraphTraversalSource}} as the other GLVs also have 
> this step.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1862) TinkerGraph VertexProgram message passing doesn't work properly when using Direction.BOTH


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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/777
  
When I run the integration tests with  `docker/build.sh -t -i` I get some 
failures in spark - do they fail for you too @PBGraff ?

```text
[ERROR] Tests run: 619, Failures: 0, Errors: 3, Skipped: 149, Time elapsed: 
237.084 s <<< FAILURE! - in 
org.apache.tinkerpop.gremlin.spark.process.computer.SparkGraphComputerProcessIntegrateTest
[ERROR] 
testMessagePassingOut(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
  Time elapsed: 0.001 s  <<< ERROR!
java.lang.UnsupportedOperationException: Graph does not support adding 
vertices
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.runTest(GraphComputerTest.java:2666)
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingOut(GraphComputerTest.java:2637)

[ERROR] 
testMessagePassingBoth(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
  Time elapsed: 0 s  <<< ERROR!
java.lang.UnsupportedOperationException: Graph does not support adding 
vertices
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.runTest(GraphComputerTest.java:2666)
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingBoth(GraphComputerTest.java:2652)

[ERROR] 
testMessagePassingIn(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
  Time elapsed: 0.001 s  <<< ERROR!
java.lang.UnsupportedOperationException: Graph does not support adding 
vertices
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.runTest(GraphComputerTest.java:2666)
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingIn(GraphComputerTest.java:2622)

[INFO] 
[INFO] Results:
[INFO] 
[ERROR] Errors: 
[ERROR] 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingBoth(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
[ERROR]   Run 1: 
GraphComputerTest.testMessagePassingBoth:2652->runTest:2666 ? 
UnsupportedOperation
[ERROR]   Run 2: 
GraphComputerTest.testMessagePassingBoth:2652->runTest:2666 ? 
UnsupportedOperation
[INFO] 
[ERROR] 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingIn(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
[ERROR]   Run 1: GraphComputerTest.testMessagePassingIn:2622->runTest:2666 
? UnsupportedOperation
[ERROR]   Run 2: GraphComputerTest.testMessagePassingIn:2622->runTest:2666 
? UnsupportedOperation
[INFO] 
[ERROR] 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingOut(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
[ERROR]   Run 1: GraphComputerTest.testMessagePassingOut:2637->runTest:2666 
? UnsupportedOperation
[ERROR]   Run 2: GraphComputerTest.testMessagePassingOut:2637->runTest:2666 
? UnsupportedOperation
[INFO] 
[INFO] 
[ERROR] Tests run: 1625, Failures: 0, Errors: 3, Skipped: 267
```


> TinkerGraph VertexProgram message passing doesn't work properly when using 
> Direction.BOTH
> -
>
> Key: TINKERPOP-1862
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1862
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process, tinkergraph
>Affects Versions: 3.2.7
>Reporter: Philip Graff
>Priority: Major
>
> I think the messages are being sent properly in TinkerMessenger, but when I 
> call messenger.receiveMessages(), the vertex is getting messages from the 
> outVertex of their edges regardless of the edge direction. This is due to 
> line 71 of TinkerMessenger (linked below) which calls 
> Edge.vertices(direction).next(), thus getting the first result out of the 
> Vertex iterator. For IN or OUT, this isn't a problem. But for BOTH, following 
> line 124 of TinkerEdge (linked below), the outVertex is always returned 
> first. TinkerMessenger needs to be modified to return the correct vertex (I 
> think it's the one that != this.vertex).
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/process/computer/TinkerMessenger.java#L71
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerEdge.java#L124



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #777: TINKERPOP-1862 TinkerMessenger proper handling of Dire...

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/777
  
When I run the integration tests with  `docker/build.sh -t -i` I get some 
failures in spark - do they fail for you too @PBGraff ?

```text
[ERROR] Tests run: 619, Failures: 0, Errors: 3, Skipped: 149, Time elapsed: 
237.084 s <<< FAILURE! - in 
org.apache.tinkerpop.gremlin.spark.process.computer.SparkGraphComputerProcessIntegrateTest
[ERROR] 
testMessagePassingOut(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
  Time elapsed: 0.001 s  <<< ERROR!
java.lang.UnsupportedOperationException: Graph does not support adding 
vertices
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.runTest(GraphComputerTest.java:2666)
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingOut(GraphComputerTest.java:2637)

[ERROR] 
testMessagePassingBoth(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
  Time elapsed: 0 s  <<< ERROR!
java.lang.UnsupportedOperationException: Graph does not support adding 
vertices
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.runTest(GraphComputerTest.java:2666)
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingBoth(GraphComputerTest.java:2652)

[ERROR] 
testMessagePassingIn(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
  Time elapsed: 0.001 s  <<< ERROR!
java.lang.UnsupportedOperationException: Graph does not support adding 
vertices
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.runTest(GraphComputerTest.java:2666)
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingIn(GraphComputerTest.java:2622)

[INFO] 
[INFO] Results:
[INFO] 
[ERROR] Errors: 
[ERROR] 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingBoth(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
[ERROR]   Run 1: 
GraphComputerTest.testMessagePassingBoth:2652->runTest:2666 ? 
UnsupportedOperation
[ERROR]   Run 2: 
GraphComputerTest.testMessagePassingBoth:2652->runTest:2666 ? 
UnsupportedOperation
[INFO] 
[ERROR] 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingIn(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
[ERROR]   Run 1: GraphComputerTest.testMessagePassingIn:2622->runTest:2666 
? UnsupportedOperation
[ERROR]   Run 2: GraphComputerTest.testMessagePassingIn:2622->runTest:2666 
? UnsupportedOperation
[INFO] 
[ERROR] 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingOut(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
[ERROR]   Run 1: GraphComputerTest.testMessagePassingOut:2637->runTest:2666 
? UnsupportedOperation
[ERROR]   Run 2: GraphComputerTest.testMessagePassingOut:2637->runTest:2666 
? UnsupportedOperation
[INFO] 
[INFO] 
[ERROR] Tests run: 1625, Failures: 0, Errors: 3, Skipped: 267
```


---

[GitHub] tinkerpop issue #779: Apply edgeFunction in SparkMessenger

2018-01-16 Thread dkuppitz

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/779
  
Can you please a) create a Jira ticket for this issue (then rename the PR 
accordingly) and b) add a test case, that would fail without this change?


---

[GitHub] tinkerpop issue #780: improve performace by not handling excepptions

2018-01-16 Thread dkuppitz

Github user dkuppitz commented on the issue:

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


---

[jira] [Commented] (TINKERPOP-1870) n^2 synchronious operation in OLAP WorkerExecutor.execute() method


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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/778
  
I was about to ask for more details on how much of an improvement this was 
in terms of performance, but it's on the JIRA issue - for others reviewing, 
please see:

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


> n^2 synchronious operation in OLAP WorkerExecutor.execute() method
> --
>
> Key: TINKERPOP-1870
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1870
> Project: TinkerPop
>  Issue Type: Improvement
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Artem Aliev
>Priority: Major
> Attachments: findTraverser1.png, findTraverser2.png, 
> findTraverserFixed.png
>
>
> [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/traversal/WorkerExecutor.java#L80-L93]
> This block of code iterates over all remote traverses to select one related 
> to the current vertex and remove it. This operation is repeated for the next 
> vertex and so one. For following example query it means n^2 operations (n is 
> number of vertices). All of them in sync block. multi core spark executor 
> will do this operations serial. 
> {code}
> g.V().emit().repeat(both().dedup()).count().next()
> {code}
> See jvisualvm screenshot. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #778: TINKERPOP-1870: Extends TraverserSet to have Vertex in...

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/778
  
I was about to ask for more details on how much of an improvement this was 
in terms of performance, but it's on the JIRA issue - for others reviewing, 
please see:

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


---

[GitHub] tinkerpop pull request #778: TINKERPOP-1870: Extends TraverserSet to have Ve...

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

https://github.com/apache/tinkerpop/pull/778#discussion_r161835490
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/gryo/GryoVersion.java
 ---
@@ -305,6 +307,7 @@ public String getVersion() {
 add(GryoTypeReg.of(RangeGlobalStep.RangeBiOperator.class, 
114));
 add(GryoTypeReg.of(OrderGlobalStep.OrderBiOperator.class, 118, 
new JavaSerializer()));
 add(GryoTypeReg.of(ProfileStep.ProfileBiOperator.class, 119));
+add(GryoTypeReg.of(VertexTraverserSet.class, 173));
--- End diff --

please move the "last id" comment down from:


https://github.com/apache/tinkerpop/pull/778/files#diff-f1eb3822f6d5659dd2bdc913ae475241R208

you might need to create a separate PR against master for us to review 
because of this change because Gryo 3.0 will need a similar entry on master (i 
suspect the kryo id will be different) and we'd need to be sure this all works 
on master as well.


---

[jira] [Commented] (TINKERPOP-1870) n^2 synchronious operation in OLAP WorkerExecutor.execute() method


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

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

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

https://github.com/apache/tinkerpop/pull/778#discussion_r161835490
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/gryo/GryoVersion.java
 ---
@@ -305,6 +307,7 @@ public String getVersion() {
 add(GryoTypeReg.of(RangeGlobalStep.RangeBiOperator.class, 
114));
 add(GryoTypeReg.of(OrderGlobalStep.OrderBiOperator.class, 118, 
new JavaSerializer()));
 add(GryoTypeReg.of(ProfileStep.ProfileBiOperator.class, 119));
+add(GryoTypeReg.of(VertexTraverserSet.class, 173));
--- End diff --

please move the "last id" comment down from:


https://github.com/apache/tinkerpop/pull/778/files#diff-f1eb3822f6d5659dd2bdc913ae475241R208

you might need to create a separate PR against master for us to review 
because of this change because Gryo 3.0 will need a similar entry on master (i 
suspect the kryo id will be different) and we'd need to be sure this all works 
on master as well.


> n^2 synchronious operation in OLAP WorkerExecutor.execute() method
> --
>
> Key: TINKERPOP-1870
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1870
> Project: TinkerPop
>  Issue Type: Improvement
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Artem Aliev
>Priority: Major
> Attachments: findTraverser1.png, findTraverser2.png, 
> findTraverserFixed.png
>
>
> [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/traversal/WorkerExecutor.java#L80-L93]
> This block of code iterates over all remote traverses to select one related 
> to the current vertex and remove it. This operation is repeated for the next 
> vertex and so one. For following example query it means n^2 operations (n is 
> number of vertices). All of them in sync block. multi core spark executor 
> will do this operations serial. 
> {code}
> g.V().emit().repeat(both().dedup()).count().next()
> {code}
> See jvisualvm screenshot. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1861) VertexProgram create with varargs for Graphs


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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/772
  
> My concern is that people may still override/implement the old method and 
not the new one, thus yielding programs that don't execute properly

Hmmas I look at the way it is now, you mention a valid concern. This 
change effectively breaks existing `VertexProgram` implementations, doesn't it? 
Meaning, nothing in TinkerPop calls the deprecated method anymore, so existing 
`VertexProgram` implementations will no longer have the old method called at 
runtime - it will call the empty default method instead here:


https://github.com/apache/tinkerpop/pull/772/files#diff-ca108f45ec7b5a288dfce8019f1a6813L72

Perhaps the right way to do this is to:

1. Make the new method call the deprecated one by default. In that way, 
existing `VertexProgram` implementations just work on upgrade. Leave the 
deprecated one empty.
2. Our `VertexProgram` implementations implement the new method, so they 
will all work without a problem. The old deprecated method should be 
implemented on these classes to call the new method. This way, if someone (for 
some weird reason) is relying on the behavior of the old method it will still 
work without change (you would need to add appropriate deprecation 
annotation/javadoc here.
3. People who write new `VertexProgram` implementations wouldn't bother 
with the old deprecated method - perhaps some stronger language in the javadoc 
would make that clear to them.
3. Write [upgrade 
docs](https://github.com/apache/tinkerpop/blob/tp32/docs/src/upgrade/release-3.2.x-incubating.asciidoc)
 to describe the new expectations around `VertexProgram` implementations and 
include a changelog entry - i can do that if you like on merge.

How does that sound? 

btw, sorry - this is turning into a complicated PR - thanks for continuing 
to work through this with us.



> VertexProgram create with varargs for Graphs
> 
>
> Key: TINKERPOP-1861
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1861
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.7
>Reporter: Philip Graff
>Priority: Minor
>
> VertexProgram.Builder.create(Graph) can be modified to 
> VertexProgram.Builder.create(Graph...) so that passing in zero or many graphs 
> is naturally handled. The current state of passing in null when no graph is 
> needed is bad practice.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #772: TINKERPOP-1861 Modify VertexProgram Builder to take va...

Github user spmallette commented on the issue:

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

> My concern is that people may still override/implement the old method and
not the new one, thus yielding programs that don't execute properly

Hmmas I look at the way it is now, you mention a valid concern. This
change effectively breaks existing `VertexProgram` implementations, doesn't it?
Meaning, nothing in TinkerPop calls the deprecated method anymore, so existing
`VertexProgram` implementations will no longer have the old method called at
runtime - it will call the empty default method instead here:

https://github.com/apache/tinkerpop/pull/772/files#diff-ca108f45ec7b5a288dfce8019f1a6813L72

Perhaps the right way to do this is to:

1. Make the new method call the deprecated one by default. In that way,
existing `VertexProgram` implementations just work on upgrade. Leave the
deprecated one empty.
2. Our `VertexProgram` implementations implement the new method, so they
will all work without a problem. The old deprecated method should be
implemented on these classes to call the new method. This way, if someone (for
some weird reason) is relying on the behavior of the old method it will still
work without change (you would need to add appropriate deprecation
annotation/javadoc here.
3. People who write new `VertexProgram` implementations wouldn't bother
with the old deprecated method - perhaps some stronger language in the javadoc
would make that clear to them.
3. Write [upgrade
docs](https://github.com/apache/tinkerpop/blob/tp32/docs/src/upgrade/release-3.2.x-incubating.asciidoc)
to describe the new expectations around `VertexProgram` implementations and
include a changelog entry - i can do that if you like on merge.

How does that sound?

btw, sorry - this is turning into a complicated PR - thanks for continuing
to work through this with us.

---

[jira] [Commented] (TINKERPOP-1861) VertexProgram create with varargs for Graphs


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

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

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

https://github.com/apache/tinkerpop/pull/772#discussion_r161791620
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/VertexProgram.java
 ---
@@ -219,13 +234,28 @@ public default void workerIterationEnd(final Memory 
memory) {
  * @paramThe vertex program type
  * @return the newly constructed vertex program
  */
+@Deprecated
--- End diff --

you need a "@deprecated" javadoc here.


> VertexProgram create with varargs for Graphs
> 
>
> Key: TINKERPOP-1861
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1861
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.7
>Reporter: Philip Graff
>Priority: Minor
>
> VertexProgram.Builder.create(Graph) can be modified to 
> VertexProgram.Builder.create(Graph...) so that passing in zero or many graphs 
> is naturally handled. The current state of passing in null when no graph is 
> needed is bad practice.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #776: TINKERPOP-1868 Gremlin.Net: Add Inject step to GraphTr...

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/776
  
If this is a breaking change for .NET users in some way, it would be good 
to write something in the upgrade documentation about it.  A changelog entry 
would also be good (either way). 


---

[jira] [Commented] (TINKERPOP-1868) Support inject source step in Gremlin.Net


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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/776
  
If this is a breaking change for .NET users in some way, it would be good 
to write something in the upgrade documentation about it.  A changelog entry 
would also be good (either way). 


> Support inject source step in Gremlin.Net
> -
>
> Key: TINKERPOP-1868
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1868
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Priority: Minor
>
> {{GraphTraversalSource}} has no {{Inject}} step in Gremlin.Net because it's 
> explicitly excluded in the GLV generation:
> {code}
> "sourceSpawnMethods": GraphTraversalSource.getMethods(). // SPAWN STEPS
> findAll { GraphTraversal.class.equals(it.returnType) 
> && !it.name.equals('inject')}.
> // ...
> {code}
> I don't know why {{inject}} is explicitly excluded here, but there should be 
> an implementation in {{GraphTraversalSource}} as the other GLVs also have 
> this step.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1489) Provide a Javascript Gremlin Language Variant


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

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

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/695
  
I've just noticed that there isn't a `g:T` deserializer, I'll add it in the 
next days.


> Provide a Javascript Gremlin Language Variant
> -
>
> Key: TINKERPOP-1489
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1489
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: javascript
>Affects Versions: 3.2.5
>Reporter: Jorge Bay
>Priority: Major
>
> It would be nice to have a Javascript Gremlin Language Variant that could 
> work with any ES5 runtime, specially the ones that support 
> [CommonJs|http://requirejs.org/docs/commonjs.html], like Node.js.
> Nashorn, the engine shipped with JDK 8+, does not implement CommonJs but 
> provides [additional 
> extensions|https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions] 
> making modular JavaScript possible. Nashorn should be supported in order to 
> run glv tests under the same infrastructure (JDK8).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1858) HttpChannelizer regression: Does not create specified AuthenticationHandler


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

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

Github user asfgit closed the pull request at:

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


> HttpChannelizer regression: Does not create specified AuthenticationHandler
> ---
>
> Key: TINKERPOP-1858
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1858
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.3.0
> Environment: All
>Reporter: Keith Lohnes
>Priority: Major
>  Labels: easyfix, regression
> Fix For: 3.3.2
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> HttpChannelizer creates a HttpBasicAuthenticationHandler instead of 
> instantiating the specified AuthenticationHandler from the configuration



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TINKERPOP-1858) HttpChannelizer regression: Does not create specified AuthenticationHandler

2018-01-16 Thread stephen mallette (JIRA)


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

stephen mallette closed TINKERPOP-1858.
---
   Resolution: Fixed
 Assignee: stephen mallette
Fix Version/s: 3.3.2

> HttpChannelizer regression: Does not create specified AuthenticationHandler
> ---
>
> Key: TINKERPOP-1858
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1858
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.3.0
> Environment: All
>Reporter: Keith Lohnes
>Assignee: stephen mallette
>Priority: Major
>  Labels: easyfix, regression
> Fix For: 3.3.2
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> HttpChannelizer creates a HttpBasicAuthenticationHandler instead of 
> instantiating the specified AuthenticationHandler from the configuration



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop pull request #767: TINKERPOP-1858: HttpChannelizer Regression: Doe...

2018-01-16 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[jira] [Closed] (TINKERPOP-1860) valueMap(True) result in error in gremlin-python

2018-01-16 Thread stephen mallette (JIRA)


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

stephen mallette closed TINKERPOP-1860.
---
   Resolution: Fixed
 Assignee: stephen mallette
Fix Version/s: 3.3.2
   3.2.8

> valueMap(True) result in error in gremlin-python
> 
>
> Key: TINKERPOP-1860
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1860
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.3.0
> Environment: Windows 10
> jvm 1.8, python 3.5
> tinkerpop 3.3.0
>Reporter: yokota masanori
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.8, 3.3.2
>
>
> I use [True] value as a argument of valueMap() step.  And it result in error 
> as below.
> (This error didn't occur in Groovy Query and return list of Value Map with id 
> and label)
> // Python 
> graph = Graph()
> g = 
> graph.traversal().withRemote(DriverRemoteConnection('ws://localhost:8182/gremlin','g'))
> g.V().valueMap(True).toList()
> =>
> TypeError 
> > 1 g.V().valueMap(True).toList()
>  ...
>  ~\site-packages\gremlin_python\structure\io\graphsonV3d0.py in 
> objectify(cls, l, reader)
> 453 x = 0
> 454 while x < len(l):
> --> 455 new_dict[reader.toObject(l[x])] = reader.toObject(l[x 
> + 1])
> 456 x = x + 2
> 457 return new_dict
> TypeError: unhashable type: 'dict'



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1860) valueMap(True) result in error in gremlin-python


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

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

Github user asfgit closed the pull request at:

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


> valueMap(True) result in error in gremlin-python
> 
>
> Key: TINKERPOP-1860
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1860
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.3.0
> Environment: Windows 10
> jvm 1.8, python 3.5
> tinkerpop 3.3.0
>Reporter: yokota masanori
>Priority: Minor
>
> I use [True] value as a argument of valueMap() step.  And it result in error 
> as below.
> (This error didn't occur in Groovy Query and return list of Value Map with id 
> and label)
> // Python 
> graph = Graph()
> g = 
> graph.traversal().withRemote(DriverRemoteConnection('ws://localhost:8182/gremlin','g'))
> g.V().valueMap(True).toList()
> =>
> TypeError 
> > 1 g.V().valueMap(True).toList()
>  ...
>  ~\site-packages\gremlin_python\structure\io\graphsonV3d0.py in 
> objectify(cls, l, reader)
> 453 x = 0
> 454 while x < len(l):
> --> 455 new_dict[reader.toObject(l[x])] = reader.toObject(l[x 
> + 1])
> 456 x = x + 2
> 457 return new_dict
> TypeError: unhashable type: 'dict'



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop pull request #773: TINKERPOP-1860 Added tests for valueMap(true) v...

2018-01-16 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[GitHub] tinkerpop pull request #774: TINKERPOP-1860 valueMap(true) support/testing

2018-01-16 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[GitHub] tinkerpop pull request #780: improve performace by not handling excepptions

2018-01-16 Thread artem-aliev

GitHub user artem-aliev opened a pull request:

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

improve performace by not handling excepptions



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

$ git pull https://github.com/artem-aliev/tinkerpop TINKERPOP-1871

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

https://github.com/apache/tinkerpop/pull/780.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 #780


commit 7197a89e696a9cb9ff93081510de17e5d016b858
Author: artemaliev 
Date:   2017-12-29T09:49:28Z

improve performace by not handling excepptions




---

[jira] [Created] (TINKERPOP-1871) Exception handling is slow in element ReferenceElement creation

Artem Aliev created TINKERPOP-1871:
--

 Summary: Exception handling is slow in element  ReferenceElement 
creation
 Key: TINKERPOP-1871
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1871
 Project: TinkerPop
  Issue Type: Improvement
Affects Versions: 3.3.1
Reporter: Artem Aliev


Following exception happen for each vertex in OLAP and takes ~10% of execution 
time.

[https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/reference/ReferenceElement.java#L48]

The exception is always thrown for ComputerGraph.ComputerAdjacentVertex class.

So the check could be added to improve performance. This is 3.3.x issue only, 
3.2 has no this problem.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TINKERPOP-1870) n^2 synchronious operation in OLAP WorkerExecutor.execute() method


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

Artem Aliev updated TINKERPOP-1870:
---
Affects Version/s: 3.2.7
   3.3.1

> n^2 synchronious operation in OLAP WorkerExecutor.execute() method
> --
>
> Key: TINKERPOP-1870
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1870
> Project: TinkerPop
>  Issue Type: Improvement
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Artem Aliev
>Priority: Major
> Attachments: findTraverser1.png, findTraverser2.png, 
> findTraverserFixed.png
>
>
> [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/traversal/WorkerExecutor.java#L80-L93]
> This block of code iterates over all remote traverses to select one related 
> to the current vertex and remove it. This operation is repeated for the next 
> vertex and so one. For following example query it means n^2 operations (n is 
> number of vertices). All of them in sync block. multi core spark executor 
> will do this operations serial. 
> {code}
> g.V().emit().repeat(both().dedup()).count().next()
> {code}
> See jvisualvm screenshot. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1870) n^2 synchronious operation in OLAP WorkerExecutor.execute() method


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

Artem Aliev commented on TINKERPOP-1870:


I wrapped the block into findVertexTraverser() method to see its timing in 
profiler. See attached profiler screenshots

So it takes 20-30% of execution time in single 6 core executor. The performance 
was was greatly improved on my 10k vertex graph:

Before fix:
{code}

gremlin> g.V().count()
==>1
gremlin> g.E().count()
==>16

gremlin> clock(1) \{g.V().emit().repeat(both().dedup()).count().next()}
==>52349.640981
gremlin> clock(1) \{g.V().emit().repeat(both().dedup()).count().next()}
==>53800.89875495
gremlin> clock(1) \{g.V().emit().repeat(both().dedup()).count().next()}
==>50643.744645

{code}

After fix:
{code}

gremlin> clock(1) \{g.V().emit().repeat(both().dedup()).count().next()}
==>42062.945477
gremlin> clock(1) \{g.V().emit().repeat(both().dedup()).count().next()}
==>38419.46317196
gremlin> clock(1) \{g.V().emit().repeat(both().dedup()).count().next()}
==>34336.707208

{code}

{code}
>mvn clean install
[INFO] BUILD SUCCESS
{code}

> n^2 synchronious operation in OLAP WorkerExecutor.execute() method
> --
>
> Key: TINKERPOP-1870
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1870
> Project: TinkerPop
>  Issue Type: Improvement
>Reporter: Artem Aliev
>Priority: Major
> Attachments: findTraverser1.png, findTraverser2.png, 
> findTraverserFixed.png
>
>
> [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/computer/traversal/WorkerExecutor.java#L80-L93]
> This block of code iterates over all remote traverses to select one related 
> to the current vertex and remove it. This operation is repeated for the next 
> vertex and so one. For following example query it means n^2 operations (n is 
> number of vertices). All of them in sync block. multi core spark executor 
> will do this operations serial. 
> {code}
> g.V().emit().repeat(both().dedup()).count().next()
> {code}
> See jvisualvm screenshot. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TINKERPOP-1870) n^2 synchronious operation in OLAP WorkerExecutor.execute() method