[jira] [Commented] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-887:
--

A couple of more things:

1. You will need to create serializers for this in Gryo, GraphSON, and in 
Gremlin-Python.
2. You should make an example of this working. In your PR so we can see its 
usefulness. Provide a Gremlin Console session showing what the problem is now 
and how your PR makes this better.

Finally, if you want this enabled for all traversals either you do 
{{g.withStrategies()}} or the user updates the 
{{TraversalStrategies.GlobalCache}} to have it turned on all the time. Having 
it on all the time isn't necessary.

Regarding "performance impact" -- its more of a problem with "just more stuff" 
that interacts at the {{TraversalStrategy}} level. We are always trying to get 
rid of strategies (e.g. {{IdentityRemovalStrategy}} --- its "just a noop 
too!"). Less less less... not "thanks for adding things" cause guess who gets 
to maintain your one off idea -- exactly.



> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

[jira] [Commented] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-887:
--

The less logic the better. If you want to debug your traversal, you do 
{{g.withStrategies(ExceptionHandlingStrategy)}}. Adding strategies is not 
something to do willy nilly.

> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

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

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Closed] (TINKERPOP-919) Features needs to specify whether 2 vertex properties with same key/value is allowed.

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-919.
--
   Resolution: Done
Fix Version/s: 3.2.4

> 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
> Fix For: 3.2.4
>
>
> 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 pull request #463: TINKERPOP-919 Added supportsDuplicateMultiPrope...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #446: TINKERPOP-1483: valueMap should always return string k...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
I've seen lots of code where people actually use `id` as a property name.

```
gremlin> g = TinkerGraph.open().traversal()
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
gremlin> g.addV().property("id", UUID.randomUUID())
==>v[0]
gremlin> g.V().valueMap(true)
==>[id:0,id:[02f29cc6-7f04-477c-a884-d5196064109a],label:vertex]
gremlin> g.V().project("vertexId","applicationId").by(id).by("id").next()
==>vertexId=0
==>applicationId=02f29cc6-7f04-477c-a884-d5196064109a
```

Those people would be in big trouble if we would merge this PR:

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-887) FastNoSuchElementException hides stack trace in client code

[Bryn Cooke (JIRA)]

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

Bryn Cooke commented on TINKERPOP-887:
--

Is this really going to make a difference to performance? The added step is 
basically a no-op, so unless there is definitely a performance degradation then 
it'd be better to avoid the extra complexity for users having to enable a 
special mode. Perhaps we can evaluate the perf impact before going down this 
route?

If we did have to have a special mode then how would this be activated? 
Say you have a 100 line gremlin script that you are submitting to gremlin 
server, you'd want to enable this mode for all traversals in the request. That 
way when the error occurs you can tell which line it occurred on. Perhaps 
[~spmallette] has some ideas? Ideally I would like to avoid having to put the 
entire server in to debug mode.



> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

[GitHub] tinkerpop issue #461: TINKERPOP-932 Added "force" option on session close.

[dkuppitz]

Github user dkuppitz commented on the issue:

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

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

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/463
  
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-919) Features needs to specify whether 2 vertex properties with same key/value is allowed.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-919:
--

Github user dkuppitz commented on the issue:

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


> 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)

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

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

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

[dkuppitz]

Github user dkuppitz commented on the issue:

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

Re: Code Reviews - for committers

[Daniel Kuppitz]

Talking about sparing CPU cycles: docker/build.sh -t -i -n takes time, lots
of time. I used to run it regardless of whether somebody else already did
it or not. I won't do that anymore and instead rely on idempotent results
(in the end that's why we originally created the Docker containers). Hence,
if anybody already ran the full build, I will only look through the code
changes and if they look good to me - VOTE: +1.

Cheers,
Daniel


On Fri, Oct 28, 2016 at 9:28 PM, Stephen Mallette 
wrote:

> We're backing up pretty heavily on pull request reviews/votes.
>
> https://github.com/apache/tinkerpop/pulls
>
> Can any committers help us along with some reviews/votes?
>
> Remember - you don't need to have full knowledge of the code to participate
> in a code review. If the code comes from a core contributor (e.g. marko
> submitting a gremlin-spark bug fix), you mostly need to focus on the big
> picture and generalities of the change and then do a "mvn clean install" or
> better yet "docker.build.sh -t -i -n". If it all works then "VOTE +1".
>
> Most pull requests for review are super simple, like this one:
>
> https://github.com/apache/tinkerpop/pull/465 (removed deprecated classes)
>
> All you need to do is check if the classes are gone, if upgrade docs are
> updated and if the thing builds...done. VOTE +1.
>
> Doing reviews is a huge help to the project (even for those who are not
> committers and don't have binding votes, as it is a great way to get
> visibility in the project and learn more about how it works). It would be
> great if folks could make a habit of sparing a few CPU cycles for TinkerPop
> at the end of a work day or while you sleep so that we can continue to stay
> agile in our development.
>
> Thanks
>

[GitHub] tinkerpop issue #458: Message scope initialization in PeerPressureVertexProg...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/458
  
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-1527) Do not override registered strategies in TraversalStrategies.GlobalCache

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

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


> 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-1235) Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

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


> 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 issue #465: TINKERPOP-1235 Removed deprecated "performance" tests.

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/465
  
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-887) FastNoSuchElementException hides stack trace in client code

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Why is this a default strategy? This should be more of a "turn it on if you 
are testing." We shouldn't waste clock cycles on every traversal.


> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

[GitHub] tinkerpop issue #470: TINKERPOP-887 ExceptionHandlerStrategy

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Why is this a default strategy? This should be more of a "turn it on if you 
are testing." We shouldn't waste clock cycles on every traversal.


---
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] [Updated] (TINKERPOP-1030) Map common exceptions to HTTP status codes where possible

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1030:

Assignee: (was: stephen mallette)

> Map common exceptions to HTTP status codes where possible
> -
>
> Key: TINKERPOP-1030
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1030
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.0-incubating
>Reporter: stephen mallette
>Priority: Trivial
>
> If a script throws an exception in the REST API, it would be nice if there 
> was a way to map that exception to an HTTP status code.  The gremlin server 
> configuration could have a specific set of exception to error code mappings.



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

[jira] [Closed] (TINKERPOP-893) Validate dependency grabs that have TinkerPop dependencies

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-893.
--
Resolution: Won't Fix
  Assignee: stephen mallette

I was thinking about this one today while doing some testing that involved 
mucking with dependency exclusions. I sense that implementation of this ticket 
is just going to end up being fairly superficial. Even eliminating jar 
conflicts at a TinkerPop level doesn't help prevent problems as there are even 
conflicts within TinkerPop (i.e. spark-gremlin with gremlin-console - luckily 
that's never caused problems). Something way more advanced would be required to 
really prevent these kinds of issues and would likely take us out of scope of 
what TinkerPop is focused on. Users will just have to take care in their 
install commands and resolve conflict on their own.

> Validate dependency grabs that have TinkerPop dependencies
> --
>
> Key: TINKERPOP-893
> URL: https://issues.apache.org/jira/browse/TINKERPOP-893
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console, server
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Trivial
>
> Gremlin Console's {{:install}} command:
> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-console/src/main/groovy/org/apache/tinkerpop/gremlin/console/commands/InstallCommand.groovy
> and Gremlin Server's {{bin/gremlin-server.sh -i}} 
> https://github.com/apache/incubator-tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/util/GremlinServerInstall.java
> pull down dependencies.  A nice check might be to detect dependency conflicts 
> with TinkerPop libs.  For example, if someone tries to use Gremlin 3.1.0 to 
> {{install}} Titan 1.0.0 (which depends on TinkerPop 3.0.1), we could error 
> the install and show a nice error to the user.



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

[jira] [Reopened] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code

[Bryn Cooke (JIRA)]

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

Bryn Cooke reopened TINKERPOP-887:
--

Please could you take a look at the PR and see if it has any potential?
It adds a new strategy that appends a final step to top level traversals that 
converts any FastNoSuchElementException in to a regular NoSuchElementException. 
It means that we don't get the stack trace in to the traversal, but clients do 
get information about where in their code the exception was thrown.

> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

[jira] [Commented] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-887:
--

GitHub user BrynCooke opened a pull request:

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

TINKERPOP-887 ExceptionHandlerStrategy

Added exception handler strategy to convert FastNoSuchElementExceptions in 
to regular NoSuchElementExceptions when exiting a traversal.

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

$ git pull https://github.com/BrynCooke/incubator-tinkerpop TINKERPOP-887

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

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


commit 4b80bcd2f12b905a927d61e257c2d4b00f76f609
Author: BrynCooke 
Date:   2016-10-28T19:04:10Z

TINKERPOP-887 Added exception handler strategy to convert 
FastNoSuchElementExceptions in to regular NoSuchElementExceptions when exiting 
a traversal.




> FastNoSuchElementException hides stack trace in client code
> ---
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Bryn Cooke
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> I wrote some code that incorrectly assumed that a Gremlin query would return 
> an element, but it didn't. The surprise was that I got no stack trace and 
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional 
> circumstances then why is a singleton is used over a normal exception with 
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it 
> shouldn't. Code should check hasNext rather than trying for next and dealing 
> with an exceptional result. I'm not sure what the current state of things are 
> in the JVM but at least in the past try catch blocks would inhibit 
> optimization even without stack traces so this type of code was considered an 
> antipattern.



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

[GitHub] tinkerpop pull request #470: TINKERPOP-887 ExceptionHandlerStrategy

[BrynCooke]

GitHub user BrynCooke opened a pull request:

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

TINKERPOP-887 ExceptionHandlerStrategy

Added exception handler strategy to convert FastNoSuchElementExceptions in 
to regular NoSuchElementExceptions when exiting a traversal.

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

$ git pull https://github.com/BrynCooke/incubator-tinkerpop TINKERPOP-887

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

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


commit 4b80bcd2f12b905a927d61e257c2d4b00f76f609
Author: BrynCooke 
Date:   2016-10-28T19:04:10Z

TINKERPOP-887 Added exception handler strategy to convert 
FastNoSuchElementExceptions in to regular NoSuchElementExceptions when exiting 
a traversal.




---
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-1493) Groovy project doesn't build on Windows

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/456
  
@pluradj are you going to have votes for these PRs sometime soon? i was 
sorta waiting for you to be the first to test this out.


> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



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

[GitHub] tinkerpop issue #456: TINKERPOP-1493 Groovy project doesn't build on Windows

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/456
  
@pluradj are you going to have votes for these PRs sometime soon? i was 
sorta waiting for you to be the first to test this out.


---
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-1534) Gremlin Server instances leaking in tests

[ASF GitHub Bot (JIRA)]

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

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

GitHub user spmallette opened a pull request:

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

TINKERPOP-1534 Improve GraphProvider ability to release resources

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

Specifically, made `AbstractGremlinSuite` attempt to `close()` a 
`GraphProvider` if it implemented `AutoCloseable`. Added better logging to 
`gremlin-python` server start/stop script. Removed `DriverRemoteConnectionTest` 
as it was an ignored test anyway and a remnant of the original way we tested 
`gremlin-python`. Implemented `AutoCloseable` on `RemoteGraphProvider` to kill 
Gremlin Server which is no longer started statically.

Interestingly the issue might have had less to do with "proper shutdown" 
and more with:


https://github.com/apache/tinkerpop/commit/30c2600bff074a7053cecab90baeccb60b087456

which was fixed on `tp31` and merged forward. Anyway, there should be no 
more leaking of Gremlin Server log messages into hadoop/spark/etc (i.e. 
anything after the gremlin server portion of the build).

Works with `mvn clean install`.

VOTE +1

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

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

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

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


commit 9a8c2d20ea24ed71b7b1350b9a31f27fccfb0527
Author: Stephen Mallette 
Date:   2016-10-28T15:55:47Z

TINKERPOP-1534 Improve GraphProvider ability to release resources

Specifically, made AbstractGremlinSuite attept to close() a GraphProvider 
if it implemented AutoCloseable. Added better logging to gremlin-python server 
start/stop script. Removed DriverRemoteConnectionTest as it was an ignored test 
anyway and a remnant of the original way we tested gremlin-python. Implemented 
AutoCloseable on RemoteGraphProvider to kill Gremlin Server which is no longer 
started statically.




> Gremlin Server instances leaking in tests
> -
>
> Key: TINKERPOP-1534
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1534
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server, test-suite
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.4
>
>
> Even though Gremlin Server appears to be shut down, it still produces output 
> in tests from spark/hadoop/etc.



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

[GitHub] tinkerpop pull request #469: TINKERPOP-1534 Improve GraphProvider ability to...

[spmallette]

GitHub user spmallette opened a pull request:

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

TINKERPOP-1534 Improve GraphProvider ability to release resources

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

Specifically, made `AbstractGremlinSuite` attempt to `close()` a 
`GraphProvider` if it implemented `AutoCloseable`. Added better logging to 
`gremlin-python` server start/stop script. Removed `DriverRemoteConnectionTest` 
as it was an ignored test anyway and a remnant of the original way we tested 
`gremlin-python`. Implemented `AutoCloseable` on `RemoteGraphProvider` to kill 
Gremlin Server which is no longer started statically.

Interestingly the issue might have had less to do with "proper shutdown" 
and more with:


https://github.com/apache/tinkerpop/commit/30c2600bff074a7053cecab90baeccb60b087456

which was fixed on `tp31` and merged forward. Anyway, there should be no 
more leaking of Gremlin Server log messages into hadoop/spark/etc (i.e. 
anything after the gremlin server portion of the build).

Works with `mvn clean install`.

VOTE +1

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

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

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

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


commit 9a8c2d20ea24ed71b7b1350b9a31f27fccfb0527
Author: Stephen Mallette 
Date:   2016-10-28T15:55:47Z

TINKERPOP-1534 Improve GraphProvider ability to release resources

Specifically, made AbstractGremlinSuite attept to close() a GraphProvider 
if it implemented AutoCloseable. Added better logging to gremlin-python server 
start/stop script. Removed DriverRemoteConnectionTest as it was an ignored test 
anyway and a remnant of the original way we tested gremlin-python. Implemented 
AutoCloseable on RemoteGraphProvider to kill Gremlin Server which is no longer 
started statically.




---
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-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1474:
-

I'm coming around to the side where I think we should include the properties. 
As I mentioned in my comment below, it doesn't seem like a lot of code to add. 
We would draw the line at reading the properties. I will start a thread on the 
dev list (and link it here) to make sure the community is on-board with this 
direction. [~okram] may still not like the idea though.

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



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

[DISCUSS] Properties in GLVs

[Stephen Mallette]

Note that there is an issue in JIRA that discusses whether or not we should
include properties on Vertex/Edge/VertexProperty structure classes in the
GLVs. I've personally wobbled back and forth on it for a while, but I think
we should just add them with the intent to support read operations from
Gremlin Server. Ultimately, it will be the user's decision to return
properties with their Vertex/Edge/VertexProperty instances given the "mime
type" they choose for the serialization process. So users who want them get
them and those that don't (like the guy with a million multiproperties on a
Vertex) can ignore them.

Anyway, please comment on the JIRA issue if you have thoughts on the matter:

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

[jira] [Created] (TINKERPOP-1534) Gremlin Server instances leaking in tests

[stephen mallette (JIRA)]

stephen mallette created TINKERPOP-1534:
---

 Summary: Gremlin Server instances leaking in tests
 Key: TINKERPOP-1534
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1534
 Project: TinkerPop
  Issue Type: Bug
  Components: server, test-suite
Affects Versions: 3.2.3
Reporter: stephen mallette
Assignee: stephen mallette
 Fix For: 3.2.4


Even though Gremlin Server appears to be shut down, it still produces output in 
tests from spark/hadoop/etc.



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

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[Andy Tolbert (JIRA)]

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

Andy Tolbert commented on TINKERPOP-1474:
-

Just to follow up on this to make sure it doesn't slide off the radar, can I 
get some clarification on this?

{quote}
is deserializing gremlin bytecode into objects (vertex, edge, vertexproperty, 
etc.) outside the scope of gremlin-python?
{quote}

Mostly just looking for clarification for future GLV implementations.

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



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