[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=15618745#comment-15618745
 ] 

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

Github user asfgit closed the pull request at:

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


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

[GitHub] tinkerpop pull request #464: TINKERPOP-1527: Do not override registered stra...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 pull request #467: Added getProjectKeys in ProjectStep

[seanbarzilay]

Github user seanbarzilay closed the pull request at:

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


---
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 #467: Added getProjectKeys in ProjectStep

[seanbarzilay]

Github user seanbarzilay commented on the issue:

https://github.com/apache/tinkerpop/pull/467
  
@okram  wonderful


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

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> 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 #462: TINKERPOP-1525 Avoid starting VP worker iterati...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 pull request #458: Message scope initialization in PeerPressureVer...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1483) PropertyMapStep returns Map<String,E> but puts non String keys in it!

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
Yea, this is a troublesome PR. VOTE -1. 


> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is 
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in 
> Java fails. toString() are missing... But do we rely on having these keys in 
> other operations?



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

[GitHub] tinkerpop issue #467: Added getProjectKeys in ProjectStep

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/467
  
merged. in the future, please update CHANGELOG or provide a note about what 
to add to the CHANGELOG on merge. Also, I just addded you change because it was 
targeted to master and it can go in `tp32`. Also, should I want to make this an 
`UnmodifiableList` that is returned. Is that okay? thanks for the PR.


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

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/446
  
Yea, this is a troublesome 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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Huh, interesting. Sorry, currently not at a point in my day to be able to 
build and test.  Will need some more time to reason through the consequences, 
but I do appreciate the simplicity and (as @dkuppitz acknowledges), the lack of 
performance issues.

Question, does this model work with lambda steps? That is: 

```
g.V().blah().map{ x -> __.inject(x).will().not().have().anything().next() }
```



> 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 Conversion of FastNoSuchElementException...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
Huh, interesting. Sorry, currently not at a point in my day to be able to 
build and test.  Will need some more time to reason through the consequences, 
but I do appreciate the simplicity and (as @dkuppitz acknowledges), the lack of 
performance issues.

Question, does this model work with lambda steps? That is: 

```
g.V().blah().map{ x -> __.inject(x).will().not().have().anything().next() }
```



---
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=15618698#comment-15618698
 ] 

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
I've done some manual tests and all looks good to me. Although the changes 
in this PR look scary, it doesn't seem to have a bad performance impact (I 
couldn't see a performance impact at all).

With a note `CHANGELOG` and in the upgrade docs, this would be a VOTE: +1 
from my side.


> 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 Conversion of FastNoSuchElementException...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
I've done some manual tests and all looks good to me. Although the changes 
in this PR look scary, it doesn't seem to have a bad performance impact (I 
couldn't see a performance impact at all).

With a note `CHANGELOG` and in the upgrade docs, this would be a VOTE: +1 
from my side.


---
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 #468: TINKERPOP-1420 Removal of previously deprecated gremli...

[dkuppitz]

Github user dkuppitz commented on the issue:

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

```
Tests run: 490, Failures: 0, Errors: 1, Skipped: 54, Time elapsed: 32.5 sec 
<<< FAILURE! - in 
org.apache.tinkerpop.gremlin.groovy.jsr223.RemoteGraphGroovyTranslatorProcessStandardTest

g_V_repeatXunionXoutXknowsX_groupXaX_byXageX__outXcreatedX_groupXbX_byXnameX_byXcountXX_groupXaX_byXnameXX_timesX2X_capXa_bX(org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.GroupTest$Traversals)
  Time elapsed: 0.181 sec  <<< ERROR!
java.lang.NullPointerException: null
at 
org.apache.tinkerpop.gremlin.process.AbstractGremlinProcessTest.checkSideEffects(AbstractGremlinProcessTest.java:99)
at 
org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.GroupTest.g_V_repeatXunionXoutXknowsX_groupXaX_byXageX__outXcreatedX_groupXbX_byXnameX_byXcountXX_groupXaX_byXnameXX_timesX2X_capXa_bX(GroupTest.java:360)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
...
```

I restarted it, but a second attempt usually only "fixes" performance 
related issues.


---
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=15618510#comment-15618510
 ] 

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
retest this please


> 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 Conversion of FastNoSuchElementException...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
retest this please


---
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=15618497#comment-15618497
 ] 

ASF GitHub Bot commented on TINKERPOP-887:
--

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
@okram I have changed the approach entirely to avoid adding an extra 
strategy.


> 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 Conversion of FastNoSuchElementException...

[BrynCooke]

Github user BrynCooke commented on the issue:

https://github.com/apache/tinkerpop/pull/470
  
@okram I have changed the approach entirely to avoid adding an extra 
strategy.


---
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=15618334#comment-15618334
 ] 

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

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
I didn't encounter any failures with the TinkerGraph integration tests on 
Windows.


> 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 #457: TINKERPOP-1493 Groovy project doesn't build on Windows

[pluradj]

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/457
  
I didn't encounter any failures with the TinkerGraph integration tests on 
Windows.


---
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=15618329#comment-15618329
 ] 

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

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/456
  
I think this one can be closed @pauljackson, and we'll use the other one to 
merge to all the branches. 


> 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

[pluradj]

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/456
  
I think this one can be closed @pauljackson, and we'll use the other one to 
merge to all the branches. 


---
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-932) Add ability to cancel script execution associated with a Gremlin Server Session

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-932:
--

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/461
  
Tested with: `mvn clean install && mvn verify -pl gremlin-server 
-DskipIntegrationTests=false -DincludeNeo4j`

Code review LGTM.

VOTE: +1


> Add ability to cancel script execution associated with a Gremlin Server 
> Session 
> 
>
> Key: TINKERPOP-932
> URL: https://issues.apache.org/jira/browse/TINKERPOP-932
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: Zachary Kurey
>Assignee: stephen mallette
> Fix For: 3.2.4
>
>
> Currently with a {{SessionedClient}} there is no way to cancel a long running 
> script and the client has to depend on Gremlin Server side configured 
> timeouts before they can execute another script associated with the same 
> session id.
> There is a way we can forcefully close a session from the client side, or 
> just close the entire Gremlin client.  But it would be useful for client side 
> applications to be able to cancel script execution, have its intermediate 
> effects rolled back, and be able to continue interacting with the session 
> without losing session variable state maintained on the Gremlin server side.
> Unsure where this should live at an API level, since canceling by session id 
> isn't relevant for all {{Client}} implementations.  If somehow when the 
> {{CompletableFuture}} returned by {{Client.submitAsync}} could do 
> this when the {{Future}} is canceled, that would be a nice way to bridge 
> implementations.



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

[jira] [Updated] (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:all-tabpanel
 ]

stephen mallette updated TINKERPOP-1474:

Component/s: language-variant

> 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, language-variant
>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)

[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=15617713#comment-15617713
 ] 

Bryn Cooke commented on TINKERPOP-887:
--

OK. That makes sense. I had issues with an interaction with the other 
strategies that were painful to resolve. I can see that adding new strategies 
is last resort.

Taking a step back I have modified the PR so that strategies are not touched. 
It's much simpler. Please could you take another look?

I added a basic test that checks that a traversal will throw 
NoSuchElementException rather than FastNoSuchElementException. This 
demonstrates the benefit in non-gremlin server scenarios.
In future Gremlin Server can use this information to supply line precise error 
reporting, but that is outside the scope of this ticket.

If there are more tests that you would like adding please can you point me to 
the package where you would see them residing?


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