date:20161025

[jira] [Commented] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

2016-10-25 Thread ASF GitHub Bot (JIRA)


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

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

Github user asfgit closed the pull request at:

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


> Plug VertexProgram iteration leak on empty Spark RDD partitions
> ---
>
> Key: TINKERPOP-1525
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1525
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Dan LaRocque
>
> If SparkExecutor gets an RDD with empty partitions, it can invoke 
> {{VertexProgram.workerIterationStart}} without ever invoking 
> {{VertexProgram.workerIterationEnd}}.
> For vertex programs that allocate and release meaningful resources in the 
> start/end methods, this can lead to resource leaks.
> I already tested a fix that I made against the 3.2 series.  I will submit PRs 
> momentarily.



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

[GitHub] tinkerpop pull request #466: TINKERPOP-1525 Avoid starting VP worker iterati...

2016-10-25 Thread asfgit

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...

2016-10-25 Thread dalaro

Github user dalaro commented on the issue:

https://github.com/apache/tinkerpop/pull/462
  
I made a version of this change for TINKERPOP-1389 as #466.  That one's 
optional, but I thought merging this into TINKERPOP-1389 might help ensure this 
fix does not get lost in the eventual possibly-conflict-y and confusing merge 
of TINKERPOP-1389 to master.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

2016-10-25 Thread ASF GitHub Bot (JIRA)


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

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

Github user dalaro commented on the issue:

https://github.com/apache/tinkerpop/pull/462
  
I made a version of this change for TINKERPOP-1389 as #466.  That one's 
optional, but I thought merging this into TINKERPOP-1389 might help ensure this 
fix does not get lost in the eventual possibly-conflict-y and confusing merge 
of TINKERPOP-1389 to master.


> Plug VertexProgram iteration leak on empty Spark RDD partitions
> ---
>
> Key: TINKERPOP-1525
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1525
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Dan LaRocque
>
> If SparkExecutor gets an RDD with empty partitions, it can invoke 
> {{VertexProgram.workerIterationStart}} without ever invoking 
> {{VertexProgram.workerIterationEnd}}.
> For vertex programs that allocate and release meaningful resources in the 
> start/end methods, this can lead to resource leaks.
> I already tested a fix that I made against the 3.2 series.  I will submit PRs 
> momentarily.



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

[jira] [Commented] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

2016-10-25 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user dalaro opened a pull request:

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

TINKERPOP-1525 Avoid starting VP worker iterations that never end (Spark 
2.0 version)

This is exactly like #462, except that it tracks a change except it tracks 
a switch between Spark 1.6 and 2.0 away from functions that manipulate 
iterables to those that manipulate iterators.

Assuming #462 eventually gets into master, and assuming that TINKERPOP-1389 
eventually merges with master, the second merge will conflict.  It still seems 
marginally safer to make this change in parallel on TINKERPOP-1389 and 
master/tp32 than just the latter, since the conflict will look more like "oh i 
better keep one of these two almost-identical edge-case checks" than "oh the 
Spark 1.x branch had some silly edge case check that I can just delete for 2.0".

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

$ git pull https://github.com/dalaro/incubator-tinkerpop 
TINKERPOP-1525-for-TINKERPOP-1389

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

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


commit 2a8f741190beebd7b7e6a9ff7922afb9b6807fa5
Author: Dan LaRocque 
Date:   2016-10-26T00:37:17Z

Avoid starting VP worker iterations that never end

SparkExecutor.executeVertexProgramIteration was written in such a way
that an empty RDD partition would cause it to invoke
VertexProgram.workerIterationStart without ever invoking
VertexProgram.workerIterationEnd.  This seems like a contract
violation.  I have at least one VP that relies on
workerIterationStart|End to allocate and release resources.  Failing
to invoke End like this causes a leak in that VP, as it would for any
VP that uses that resource management pattern.

(cherry picked from commit 36e1159a80f539b8bd4a884e5c1cf304ec52c4f9;
 this is the same change, except it tracks a switch between Spark 1.6
 and 2.0 away from functions that manipulate iterables to those that
 manipulate iterators)




> Plug VertexProgram iteration leak on empty Spark RDD partitions
> ---
>
> Key: TINKERPOP-1525
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1525
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Dan LaRocque
>
> If SparkExecutor gets an RDD with empty partitions, it can invoke 
> {{VertexProgram.workerIterationStart}} without ever invoking 
> {{VertexProgram.workerIterationEnd}}.
> For vertex programs that allocate and release meaningful resources in the 
> start/end methods, this can lead to resource leaks.
> I already tested a fix that I made against the 3.2 series.  I will submit PRs 
> momentarily.



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

[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...

2016-10-25 Thread dalaro

Github user dalaro commented on the issue:

https://github.com/apache/tinkerpop/pull/462
  
I force-pushed this branch with a fix (`emptyIterator -> emptyList`).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-919) Features needs to specify whether 2 vertex properties with same key/value is allowed.

2016-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on TINKERPOP-919:
--

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/463
  
ok - renamed to use "duplicate" and rebased on tp32


> Features needs to specify whether 2 vertex properties with same key/value is 
> allowed.
> -
>
> Key: TINKERPOP-919
> URL: https://issues.apache.org/jira/browse/TINKERPOP-919
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure, test-suite, tinkergraph
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>
> TinkerGraph does not support two vertex properties with the same key/value.
> {code}
> gremlin> graph = TinkerGraph.open()
> ==>tinkergraph[vertices:0 edges:0]
> gremlin> v = graph.addVertex()
> ==>v[0]
> gremlin> v.property("name","marko")
> ==>vp[name->marko]
> gremlin> v.property("name","marko")
> ==>vp[name->marko]
> gremlin> v.properties("name")
> ==>vp[name->marko]
> {code}
> I just noted we don't have this as a {{Feature}} and we should (w/ respective 
> test cases).



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

[GitHub] tinkerpop issue #463: TINKERPOP-919 Added supportsDuplicateMultiProperties()

2016-10-25 Thread spmallette

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/463
  
ok - renamed to use "duplicate" and rebased on tp32


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1235) Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest

2016-10-25 Thread ASF GitHub Bot (JIRA)


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

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

GitHub user spmallette opened a pull request:

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

TINKERPOP-1235 Removed deprecated "performance" tests.

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

Also removed dependencies on `junit-benchmarks` and `h2`. This will be a 
breaking change for providers who were using these test suites. Upgrade 
documentation has been updated with respect to this issue.

Our first cleanup of "dead" code for the 3.3.x line.

all good with `mvn clean install -DincludeNeo4j`

VOTE +1

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

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

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

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


commit e376193ca247f56b9c8c2122e4f0e77e6d434375
Author: Stephen Mallette 
Date:   2016-10-25T20:04:21Z

TINKERPOP-1235 Removed deprecated "performance" tests.

Also removed dependencies on junit-benchmarks and h2. This will be a 
breaking change for providers who were using these test suites. Upgrade 
documentation has been updated with respect to this issue.




> Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest
> --
>
> Key: TINKERPOP-1235
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1235
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: test-suite
>Affects Versions: 3.2.0-incubating
>Reporter: Ted Wilmes
>Priority: Minor
>  Labels: breaking, deprecation
>
> The JUnit Benchmark based performance tests were deprecated for 
> 3.2.0-incubating given: TINKERPOP-1016 and TINKERPOP-1273



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

[GitHub] tinkerpop pull request #465: TINKERPOP-1235 Removed deprecated "performance"...

2016-10-25 Thread spmallette

GitHub user spmallette opened a pull request:

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

TINKERPOP-1235 Removed deprecated "performance" tests.

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

Also removed dependencies on `junit-benchmarks` and `h2`. This will be a 
breaking change for providers who were using these test suites. Upgrade 
documentation has been updated with respect to this issue.

Our first cleanup of "dead" code for the 3.3.x line.

all good with `mvn clean install -DincludeNeo4j`

VOTE +1

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

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

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

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


commit e376193ca247f56b9c8c2122e4f0e77e6d434375
Author: Stephen Mallette 
Date:   2016-10-25T20:04:21Z

TINKERPOP-1235 Removed deprecated "performance" tests.

Also removed dependencies on junit-benchmarks and h2. This will be a 
breaking change for providers who were using these test suites. Upgrade 
documentation has been updated with respect to this issue.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-919) Features needs to specify whether 2 vertex properties with same key/value is allowed.

2016-10-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on TINKERPOP-919:
--

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/463
  
I was a confused for a bit on the method name. Seems (and this is just me) 
that a better name would be:

```
Features.supportsDuplicateMultiPropertyValues()
```

To me this means same key, duplicate values. The problem with "identical" 
is that there is no such thing as identical as properties can have 
meta-properties and be different. Thus, its a key/value identity, not a 
key/value/properties/id identity. 

Dunno...whateves.


> Features needs to specify whether 2 vertex properties with same key/value is 
> allowed.
> -
>
> Key: TINKERPOP-919
> URL: https://issues.apache.org/jira/browse/TINKERPOP-919
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure, test-suite, tinkergraph
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>
> TinkerGraph does not support two vertex properties with the same key/value.
> {code}
> gremlin> graph = TinkerGraph.open()
> ==>tinkergraph[vertices:0 edges:0]
> gremlin> v = graph.addVertex()
> ==>v[0]
> gremlin> v.property("name","marko")
> ==>vp[name->marko]
> gremlin> v.property("name","marko")
> ==>vp[name->marko]
> gremlin> v.properties("name")
> ==>vp[name->marko]
> {code}
> I just noted we don't have this as a {{Feature}} and we should (w/ respective 
> test cases).



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

Re: PathRetractionStrategy and TraverserRequirement.PATH

2016-10-25 Thread Marko Rodriguez

Here is a simple test. Remove PathRetractionStrategy from TinkerGraph traversal 
and see what you get? Do you get what Sqlg returns or the same as if with 
PathRetractionStrategy.

E.g.

graph = TinkerFactory.createModern();
g = graph.traversal().withoutStrategies(PathRetractionStrategy.class);
g.V().the().traversal().to().test()

If you get the same answer without PathRetractionStrategy, then you know that 
Sqlg is bugged.

HTH,
Marko.

http://markorodriguez.com



> On Oct 24, 2016, at 2:21 PM, pieter-gmail  wrote:
> 
> Ok apologies. I thought I spotted the difference and simplified the
> gremlin too much to highlight what I thought I saw. The above mentioned
> queries are returning the same result in Sqlg as TinkerGraph.
> 
> Here is what is not working.
> 
>final TinkerGraph g = TinkerFactory.createModern();
>GraphTraversal>
> traversal = g.traversal()
>.V().as("a")
>.repeat(both()).times(3).emit().as("b")
>.group().by(select("a"));
>printTraversalForm(traversal);
>while (traversal.hasNext()) {
>Map vertexMap = traversal.next();
>for (Vertex vertex : vertexMap.keySet()) {
>Collection coll = vertexMap.get(vertex);
>System.out.println("key: " + vertex.value("name") + ",
> value: " + coll.size());
>}
>}
> 
> For this Sqlg has the same result as TinkerGraph.
> 
> TinkerGraph
> 
> post-strategy:[TinkerGraphStep(vertex,[])@[a],
> RepeatStep([VertexStep(BOTH,vertex),
> RepeatEndStep],until(loops(3)),emit(true))@[b],
> GroupStep([SelectOneStep(a), NoOpBarrierStep(2500)],[FoldStep])]
> 
> Sqlg
> 
> post-strategy:[SqlgGraphStepCompiled(vertex,[])@[sqlgPathFakeLabel],
> GroupStep([SelectOneStep(a)],[FoldStep])]
> 
> key: marko, value: 27
> key: vadas, value: 11
> key: lop, value: 27
> key: josh, value: 27
> key: ripple, value: 11
> key: peter, value: 11
> 
> Adding in the extra by()
> 
>final TinkerGraph g = TinkerFactory.createModern();
>GraphTraversal>
> traversal = g.traversal()
>.V().as("a")
>.repeat(both()).times(3).emit().as("b")
>.group().by(select("a"))
>.by(select("b").dedup().order().by(T.id).fold());
>printTraversalForm(traversal);
>while (traversal.hasNext()) {
>Map vertexMap = traversal.next();
>for (Vertex vertex : vertexMap.keySet()) {
>Collection coll = vertexMap.get(vertex);
>System.out.println("key: " + vertex.value("name") + ",
> value: " + coll.size());
>}
>}
> 
> TinkerGraph prints
> 
> post-strategy:[TinkerGraphStep(vertex,[])@[a],
> RepeatStep([VertexStep(BOTH,vertex),
> RepeatEndStep],until(loops(3)),emit(true))@[b],
> GroupStep([SelectOneStep(a), NoOpBarrierStep(2500)],[SelectOneStep(b),
> DedupGlobalStep, OrderGlobalStep([[id, incr]]), FoldStep])]
> 
> key: marko, value: 6
> key: vadas, value: 6
> key: lop, value: 6
> key: josh, value: 6
> key: ripple, value: 6
> key: peter, value: 6
> 
> and Sqlg
> 
> post-strategy:[SqlgGraphStepCompiled(vertex,[])@[sqlgPathFakeLabel],
> GroupStep([SelectOneStep(a)],[SelectOneStep(b), DedupGlobalStep,
> OrderGlobalStep([[id, incr]]), FoldStep])]
> 
> key: marko, value: 0
> key: ripple, value: 0
> key: peter, value: 0
> key: lop, value: 0
> key: josh, value: 0
> key: vadas, value: 0
> 
> The difference being the NoOpBarrierStep but I am not sure if that is
> the culprit or not.
> 
> Thanks
> Pieter
> 
> 
> 
> 
> 
> 
> On 24/10/2016 21:31, Marko Rodriguez wrote:
>> Hi Pieter,
>> 
>> What are the two answers --- TinkerGraph and Sqlg for the respective test 
>> traversal?
>> 
>> (I suspect the test is bad because group() pushes traversers through with 
>> bulks and all so the test might just add to a collection without adding 
>> respecting bulks. Probably should change that test regardless to do like a 
>> count or something instead).
>> 
>> Marko.
>> 
>> http://markorodriguez.com
>> 
>> 
>> 
>>> On Oct 24, 2016, at 12:57 PM, pieter-gmail  wrote:
>>> 
>>> Hi,
>>> 
>>> This is on 3.2.3
>>> 
>>> I have been investigating why
>>> `DedupTest.g_V_asXaX_repeatXbothX_timesX3X_emit_asXbX_group_byXselectXaXX_byXselectXbX_dedup_order_byXidX_foldX_selectXvaluesX_unfold_dedup`
>>> fails on Sqlg. It is a fairly recently added test.
>>> 
>>> My investigation so far has narrowed the problem to the
>>> `PathRetractionStrategy`
>>> 
>>> On the modern graph,
>>> 
>>>   GraphTraversal>
>>> traversal = g.traversal()
>>>   .V().as("a")
>>>   .out().as("b")
>>>   .group().by(select("a"))
>>>   .by(select("b"));
>>>   printTraversalForm(traversal);
>>> 
>>>

[jira] [Created] (TINKERPOP-1528) CountByIsRangeStrategy fails for a particular query

2016-10-25 Thread Daniel Kuppitz (JIRA)

Daniel Kuppitz created TINKERPOP-1528:
-

 Summary: CountByIsRangeStrategy fails for a particular query
 Key: TINKERPOP-1528
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1528
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.2.3
Reporter: Daniel Kuppitz


In a fresh TinkerGraph:

{noformat}
gremlin> g.V().count()
==>0
gremlin> g.V().count().is(0)
gremlin>
{noformat}

Because of {{.is(0)}} the traversal is converted to something like 
{{g.not(V())}}. No issues with other values (!= 0).

{noformat}
gremlin> g.addV()
==>v[0]
gremlin> g.V().count()
==>1
gremlin> g.V().count().is(0)
gremlin> g.V().count().is(1)
==>1
gremlin> g.V().count().is(2)
gremlin>
{noformat}



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

[jira] [Assigned] (TINKERPOP-1527) Do not override registered strategies in TraversalStrategies.GlobalCache

2016-10-25 Thread Marko A. Rodriguez (JIRA)


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

Marko A. Rodriguez reassigned TINKERPOP-1527:
-

Assignee: Marko A. Rodriguez

> Do not override registered strategies in TraversalStrategies.GlobalCache
> 
>
> Key: TINKERPOP-1527
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1527
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> This may be a non-issue (need to check), but we currently do this in every 
> {{Graph}} (and {{GraphComputer}}) class.
> {code}
> static {
> TraversalStrategies.GlobalCache.registerStrategies(TinkerGraph.class, 
> TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance()));
> }
> {code}
> If this static code is loaded every time a {{Graph}} instance is created, 
> then manually tweaked strategy registrations get overwritten. If this is the 
> case, then we should do:
> {code}
> static {
> 
> TraversalStrategies.GlobalCache.registerStrategiesIfNotPresent(TinkerGraph.class,TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance()));
> }
> {code}
> That is, add a {{registerIfNotPresent()}} method.



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

[jira] [Commented] (TINKERPOP-920) Test case needed for ensuring same cardinality for key.

2016-10-25 Thread stephen mallette (JIRA)


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

stephen mallette commented on TINKERPOP-920:


[~okram] this would be a nice validation except that TinkerGraph/Neo4j 
(probably others) don't have a good way to support it because they don't have a 
schema. {{Feature.getCardinality(k)}} in both TinkerGraph and Neo4j rely on 
configuration to return those values. The cardinality is either always {{list}} 
or always{{set}} or always {{single}} for them. With something like Titan you 
actually consult a schema so this would probably work better in that case, but 
that would still leave us and most providers with how to nicely implement such 
a thing.

Any ideas on what to do here? or should we just close this one?

> Test case needed for ensuring same cardinality for key.
> ---
>
> Key: TINKERPOP-920
> URL: https://issues.apache.org/jira/browse/TINKERPOP-920
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: test-suite
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>  Labels: breaking
>
> I'm note sure we have a test case for this so I will just make a ticket -- 
> please close with "won't fix" if this is already handled.
> Two properties with the same key should NOT have different cardinalities 
> because of {{Feature.getCardinality(key)}}.



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

[jira] [Commented] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

2016-10-25 Thread ASF GitHub Bot (JIRA)


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

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

Github user dalaro commented on the issue:

https://github.com/apache/tinkerpop/pull/462
  
Marko's right, I wrote and tested this against TINKERPOP-1389 (before the 
latest rebase), then cherry-picked against current master without retesting.  
Sorry about that.  He's also right about the Iterator/Iterable change.  I'll 
change it sometime today, force-push the branch, and comment.


> Plug VertexProgram iteration leak on empty Spark RDD partitions
> ---
>
> Key: TINKERPOP-1525
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1525
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Dan LaRocque
>
> If SparkExecutor gets an RDD with empty partitions, it can invoke 
> {{VertexProgram.workerIterationStart}} without ever invoking 
> {{VertexProgram.workerIterationEnd}}.
> For vertex programs that allocate and release meaningful resources in the 
> start/end methods, this can lead to resource leaks.
> I already tested a fix that I made against the 3.2 series.  I will submit PRs 
> momentarily.



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

[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...

2016-10-25 Thread dalaro

Github user dalaro commented on the issue:

https://github.com/apache/tinkerpop/pull/462
  
Marko's right, I wrote and tested this against TINKERPOP-1389 (before the 
latest rebase), then cherry-picked against current master without retesting.  
Sorry about that.  He's also right about the Iterator/Iterable change.  I'll 
change it sometime today, force-push the branch, and comment.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...

2016-10-25 Thread okram

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/462
  
This is because @dalaro is working against TINKERPOP-1389 which is Spark 
2.0. Spark 1.x returns `Iterable`, not `Iterator`. Simple to fix.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python

2016-10-25 Thread ASF GitHub Bot (JIRA)


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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/460
  
Note that the graphson.asciidoc generation isn't automatic. it's a script 
you have to run manually (so the content it generates isn't currently present 
if you were to generate docs). It can be run later i guess. Like i said, it's 
not a terribly automated process atm.

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

VOTE +1


> Pick.any and Pick.none are not in GraphSON or Gremlin-Python
> 
>
> Key: TINKERPOP-1507
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1507
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, language-variant, process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> There are numerous "tokens" (enums) in Gremlin -- {{T}}, {{Order}}, 
> {{Compare}}, etc.
> We forgot {{Pick}}. Doh. {{Pick}} is used in branch-options to support 
> "default" and "all"-type semantics in switch behavior. We need to add it to 
> GraphSON and Gremlin-Python.
> More generally, I think we should consolidate all the "tokens" into a single 
> Java file.
> {code}
> public class Tokens {
>   public enum T { .. }
>   public enum Order { .. }
>   public enum VertexCardinality { ..}
>   public enum Compare { .. }
>   public enum Pick { .. } 
>   ...
> }
> {code}
> We could make it backwards compatible by:
> {code}
> T.label = Tokens.T.label.
> {code}
> By having all this consolidate, we will more easily know what we have and 
> will be better able to use reflection in language variant generators.



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

[jira] [Commented] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

2016-10-25 Thread ASF GitHub Bot (JIRA)


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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/462
  
Travis is showing a pretty clear compilation failure:

```text
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on 
project spark-gremlin: Compilation failure
[ERROR] 
/home/travis/build/apache/tinkerpop/spark-gremlin/src/main/java/org/apache/tinkerpop/gremlin/spark/process/computer/SparkExecutor.java:[92,37]
 incompatible types: no instance(s) of type variable(s) T exist so that 
java.util.Iterator conforms to java.lang.Iterable>
```

can that be ignored?


> Plug VertexProgram iteration leak on empty Spark RDD partitions
> ---
>
> Key: TINKERPOP-1525
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1525
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Dan LaRocque
>
> If SparkExecutor gets an RDD with empty partitions, it can invoke 
> {{VertexProgram.workerIterationStart}} without ever invoking 
> {{VertexProgram.workerIterationEnd}}.
> For vertex programs that allocate and release meaningful resources in the 
> start/end methods, this can lead to resource leaks.
> I already tested a fix that I made against the 3.2 series.  I will submit PRs 
> momentarily.



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

[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...

2016-10-25 Thread spmallette

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/462
  
Travis is showing a pretty clear compilation failure:

```text
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on 
project spark-gremlin: Compilation failure
[ERROR] 
/home/travis/build/apache/tinkerpop/spark-gremlin/src/main/java/org/apache/tinkerpop/gremlin/spark/process/computer/SparkExecutor.java:[92,37]
 incompatible types: no instance(s) of type variable(s) T exist so that 
java.util.Iterator conforms to java.lang.Iterable>
```

can that be ignored?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

2016-10-25 Thread ASF GitHub Bot (JIRA)


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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/462
  
Ah. Yea -- huh. Total odd ball case, but yea, you are right. The empty 
iterator would make it so the end iteration never fires. 

VOTE +1.


> Plug VertexProgram iteration leak on empty Spark RDD partitions
> ---
>
> Key: TINKERPOP-1525
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1525
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Dan LaRocque
>
> If SparkExecutor gets an RDD with empty partitions, it can invoke 
> {{VertexProgram.workerIterationStart}} without ever invoking 
> {{VertexProgram.workerIterationEnd}}.
> For vertex programs that allocate and release meaningful resources in the 
> start/end methods, this can lead to resource leaks.
> I already tested a fix that I made against the 3.2 series.  I will submit PRs 
> momentarily.



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

[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...

2016-10-25 Thread okram

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/462
  
Ah. Yea -- huh. Total odd ball case, but yea, you are right. The empty 
iterator would make it so the end iteration never fires. 

VOTE +1.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python

2016-10-25 Thread ASF GitHub Bot (JIRA)


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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/460
  
Updated `graphson.asciidoc`.


> Pick.any and Pick.none are not in GraphSON or Gremlin-Python
> 
>
> Key: TINKERPOP-1507
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1507
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, language-variant, process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> There are numerous "tokens" (enums) in Gremlin -- {{T}}, {{Order}}, 
> {{Compare}}, etc.
> We forgot {{Pick}}. Doh. {{Pick}} is used in branch-options to support 
> "default" and "all"-type semantics in switch behavior. We need to add it to 
> GraphSON and Gremlin-Python.
> More generally, I think we should consolidate all the "tokens" into a single 
> Java file.
> {code}
> public class Tokens {
>   public enum T { .. }
>   public enum Order { .. }
>   public enum VertexCardinality { ..}
>   public enum Compare { .. }
>   public enum Pick { .. } 
>   ...
> }
> {code}
> We could make it backwards compatible by:
> {code}
> T.label = Tokens.T.label.
> {code}
> By having all this consolidate, we will more easily know what we have and 
> will be better able to use reflection in language variant generators.



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

[DISCUSS] Cleanup of dead branches

2016-10-25 Thread Daniel Kuppitz

What follows is a list of branches that qualify for the post-release
cleanup process.

TINKERPOP-1158 -- [TINKERPOP-1158] gremlin.sh -v emits log4j initialization
errors
TINKERPOP-1249 -- [TINKERPOP-1249] Gremlin driver to periodically issue
ping / heartbeat to gremlin server
TINKERPOP-1280 -- [TINKERPOP-1280] VertexPrograms should declare traverser
requirements
TINKERPOP-1330 -- [TINKERPOP-1330] by()-modulation for where()
TINKERPOP-1360 -- [TINKERPOP-1360] intermittent error in spark-gremlin
integration test
TINKERPOP-1391 -- [TINKERPOP-1391] issue with where filter
TINKERPOP-1391-master -- [TINKERPOP-1391] issue with where filter
TINKERPOP-1409 -- [TINKERPOP-1409] Make the "null" return in the gremlin
console into something more understandable
TINKERPOP-1437 -- [TINKERPOP-1437] Add tests for dedup(Scope) in DedupTest
TINKERPOP-1442 -- [TINKERPOP-1442] Killing session should make better
attempt to cleanup
TINKERPOP-1442-master -- [TINKERPOP-1442] Killing session should make
better attempt to cleanup
TINKERPOP-1444 -- [TINKERPOP-1444] Benchmark bytecode->Traversal creation
and implement GremlinServer cache if necessary.
TINKERPOP-1448 -- [TINKERPOP-1448] gremlin-python should be Python 2/3
compatible
TINKERPOP-1449 -- [TINKERPOP-1449] Streamline gremlin-python build
TINKERPOP-1451 -- [TINKERPOP-1451] TinkerGraph persistence cannot handle a
single file name as the graph location
TINKERPOP-1455 -- [TINKERPOP-1455] Provide String-based
withStrategy()/withoutStrategy() for language variant usage
TINKERPOP-1455-redux -- [TINKERPOP-1455] Provide String-based
withStrategy()/withoutStrategy() for language variant usage
TINKERPOP-1456 -- [TINKERPOP-1456] Support
SubgraphStrategy.vertexProperties().
TINKERPOP-1457 -- [TINKERPOP-1457] Groovy Lambdas for remote traversals not
serializable
TINKERPOP-1458 -- [TINKERPOP-1458] Gremlin Server doesn't return
confirmation upon Traversal OpProcessor "close" op
TINKERPOP-1464 -- [TINKERPOP-1464] Gryo Serialization for Bytecode
TINKERPOP-1467 -- [TINKERPOP-1467] Improve close() operations on the Java
driver
TINKERPOP-1467-master -- [TINKERPOP-1467] Improve close() operations on the
Java driver
TINKERPOP-1469 -- [TINKERPOP-1469] Get rid of Stream-usage in
TraversalHelper
TINKERPOP-1470 -- [TINKERPOP-1470] InlineFilterStrategy should try and
P.or() has() children in OrSteps.
TINKERPOP-1487 -- [TINKERPOP-1487] Reference Documentation for IO
TINKERPOP-1488 -- [TINKERPOP-1488] Make LazyBarrierStrategy part of the
default TraversalStrategies
TINKERPOP-1492 -- [TINKERPOP-1492] RemoteStrategy or the RemoteConnection
should append a lazy barrier().
TINKERPOP-1495 -- [TINKERPOP-1495] Global list deduplication doesn't work
in OLAP
TINKERPOP-790 -- [TINKERPOP-790] Implement AutoCloseable on TraversalSource
TINKERPOP-927 -- [TINKERPOP-927] bin/publish-docs.sh should only upload
diffs.
TINKERPOP-927-master -- [TINKERPOP-927] bin/publish-docs.sh should only
upload diffs.
TINKERPOP-944 -- [TINKERPOP-944] Deprecate Graph.Exceptions.elementNotFound

If nobody has an objections, I'm going to run the cleanup script at the end
of this week.

Cheers,
Daniel

[jira] [Commented] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

[GitHub] tinkerpop pull request #466: TINKERPOP-1525 Avoid starting VP worker iterati...

[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...

[jira] [Commented] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

[jira] [Commented] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...

[jira] [Commented] (TINKERPOP-919) Features needs to specify whether 2 vertex properties with same key/value is allowed.

[GitHub] tinkerpop issue #463: TINKERPOP-919 Added supportsDuplicateMultiProperties()

[jira] [Commented] (TINKERPOP-1235) Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest

[GitHub] tinkerpop pull request #465: TINKERPOP-1235 Removed deprecated "performance"...

[jira] [Commented] (TINKERPOP-919) Features needs to specify whether 2 vertex properties with same key/value is allowed.

Re: PathRetractionStrategy and TraverserRequirement.PATH

[jira] [Created] (TINKERPOP-1528) CountByIsRangeStrategy fails for a particular query

[jira] [Assigned] (TINKERPOP-1527) Do not override registered strategies in TraversalStrategies.GlobalCache

[jira] [Commented] (TINKERPOP-920) Test case needed for ensuring same cardinality for key.

[jira] [Commented] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...

[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...

[jira] [Commented] (TINKERPOP-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python

[jira] [Commented] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...

[jira] [Commented] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...

[jira] [Commented] (TINKERPOP-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python

[DISCUSS] Cleanup of dead branches

25 matches

Site Navigation

Mail list logo

Footer information