Re: [VOTE] TinkerPop 3.2.1 Release

Validate distribution looks good along with manual inspection of docs and testing. Thanks for putting this all together Stephen and for running me through part of the process this time. VOTE: +1 --Ted On Wed, Jul 20, 2016 at 3:42 PM, Stephen Mallette wrote: > Thanks

[RESULT][VOTE] TinkerPop 3.1.3 Release

This vote is now closed with a total of 4 +1s, no +0s and no -1s. The results are: BINDING VOTES: +1 (X -- Stephen Mallette, Daniel Kuppitz, Dylan Millikin, Ted Wilmes) 0 (0) -1 (0) I will wait to officially release 3.1.3 to go alongside the close of vote on 3.2.1 tomorrow. Thank you very

[jira] [Commented] (TINKERPOP-1383) publish-docs.sh might publish to current too early

[ https://issues.apache.org/jira/browse/TINKERPOP-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15388427#comment-15388427 ] stephen mallette commented on TINKERPOP-1383: - +1 > publish-docs.sh might publish to

Re: [DISCUSS] interrupt

Ok, np, its not serious, Postgres is the important one for me anyhow and it is behaving. I'll investigate how to tell Postgres to cancel the query. Just stopping the traversal is not quite good enough as every now and again we have queries on Postgres that persist even if the java thread dies.

Re: [DISCUSS] interrupt

> For every traversal that starts it notifies the caller via the reference object about the traversal. that's the tricky bit. you'd have to have some global tracking of spawned traversals to know that and it would have to be bound to the Thread that started it I guess. That information isn't

Re: [DISCUSS] interrupt

Well no, the problem is Thread.interrupted() is not reliable. Does not really matter who the caller is, GremlinServer or other. Just about every 3rd party library I can see might reset the flag meaning that the check will randomly return false or true. Something as trivial as a logger might even

[jira] [Updated] (TINKERPOP-1383) publish-docs.sh might publish to current too early

[ https://issues.apache.org/jira/browse/TINKERPOP-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1383: Summary: publish-docs.sh might publish to current too early (was:

[jira] [Created] (TINKERPOP-1383) publish-docs.sh might publish to current to early

stephen mallette created TINKERPOP-1383: --- Summary: publish-docs.sh might publish to current to early Key: TINKERPOP-1383 URL: https://issues.apache.org/jira/browse/TINKERPOP-1383 Project:

Re: [DISCUSS] Returning Side Effects

Your way made me think that if you wrote your traversal like that, you would return the side-effects twice - once in your traversal as part of the standard result and then again as a side-effect. Not sure what that means - just a thought. While I'm thinking thoughts that may or may not be

Re: [DISCUSS] interrupt

thanks for all that pieter. the primary reason for traversal interruption in the first place was so that gremlin server would have a chance to kill traversals that were running too long. Without a solution to that problem, I'm not sure what to do here. just tossing ideas around - could we still

Re: [DISCUSS] interrupt

I just did a global Intellij search in the Sqlg project. HSQLDB has 13 catch (InterruptedException e) clauses. All of them swallows the exception and none resets the interrupt flag. Postgresql jdbc driver has 3 catch (InterruptedException e) clauses. 2 swallows the exception without resetting

Re: [DISCUSS] interrupt

I don't recall all the issues with doing traversal interruption with a flag. I suppose it could work in the same way that thread interruption works now. I will say that I'm hesitant to say that we should change this on the basis of this being a problem general to databases as we've only seen in so

[jira] [Commented] (TINKERPOP-1380) dedup() doesn't dedup in rare cases

[ https://issues.apache.org/jira/browse/TINKERPOP-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15387444#comment-15387444 ] Daniel Kuppitz commented on TINKERPOP-1380: --- A simple test case we could add is this one:

[jira] [Comment Edited] (TINKERPOP-1380) dedup() doesn't dedup in rare cases

[ https://issues.apache.org/jira/browse/TINKERPOP-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15387407#comment-15387407 ] Daniel Kuppitz edited comment on TINKERPOP-1380 at 7/21/16 9:08 AM:

[jira] [Commented] (TINKERPOP-1380) dedup() doesn't dedup in rare cases

[ https://issues.apache.org/jira/browse/TINKERPOP-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15387407#comment-15387407 ] Daniel Kuppitz commented on TINKERPOP-1380: --- I inspected the side-effects in my original