[jira] [Commented] (TINKERPOP-2019) Gremlin.Net.Driver.WebSocketConnection throws System.InvalidOperationException
[
https://issues.apache.org/jira/browse/TINKERPOP-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036355#comment-17036355
]
Dzmitry L commented on TINKERPOP-2019:
--
Yes, I'm using CosmosDb. Reproduction steps are not clear. The bug appeared
twice on simple query like `g.V('123-123-123')`.
> Gremlin.Net.Driver.WebSocketConnection throws System.InvalidOperationException
> --
>
> Key: TINKERPOP-2019
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2019
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.3.3
> Environment: Azure App Service
>Reporter: Sami
>Priority: Critical
>
> We're getting the following {{System.InvalidOperationException}} error
> message:
> {code:c#}
> "There is already one outstanding 'SendAsync' call for this WebSocket
> instance. ReceiveAsync and SendAsync can be called simultaneously, but at
> most one outstanding operation for each of them is allowed at the same time.
> Problem Id:
> System.InvalidOperationException at
> Gremlin.Net.Driver.WebSocketConnection+d__5.MoveNext"{code}
>
> We get this exception sporadically and only a few times out of thousands.
> Unfortunately we have not been able to reproduce it.
>
> I understand that when dealing with web sockets, it is allowed to have only
> a single pending "send" or a single pending "receive".
>
> After looking at GitHub's WebSocketConnection class, I don't see any
> orchestration between SendMessageAsync's {{_client.SendAsync}} (currently
> line 54) and ReceiveMessageAsync's {{_client.ReceiveAsync}} (currently line
> 66).
>
> Reference Link:
>
> [https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/WebSocketConnection.cs]
>
> I'm wondering if not having orchestration in the WebSocketConnection class
> to keep the single pending "send" or a single pending "receive" rule may be
> the cause.
>
> In our .NET Core web api application, we create the GremlinConnection as a
> singleton in Startup.cs and then have one central call that makes Gremlin
> calls; i.e. it's a very straightforward implementation.
>
> Startup.cs:
> {code:c#}
> public void ConfigureServices(IServiceCollection services)
> {
> //...other stuff removed for brevity
> services.AddSingleton();
> }{code}
>
> Reader.cs:
> {code:c#}
> public async Task> ExecuteGremlinQuery(string
> query)
> {
> try
> {
> return await _gremlinConnection.Client.SubmitAsync(query);
> }
> catch (Gremlin.Net.Driver.Exceptions.ResponseException responseException)
> {
> //our error handling removed for brevity!
> }
> }{code}
>
> We use the Gremlin.Net version 3.3.3 nuget package and the
> Microsoft.NETCore.App SDK
>
> Would it be possible to identify if this is indeed a bug on Gremlin.NET?
> And if it is, any thoughts on a best-practice (temporary) work-around that
> we can implement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [tinkerpop] spmallette commented on issue #1245: TINKERPOP-2338 Fix bug in drop() of edge/meta properties
Not sure what's wrong with travis - both are failing due to the docker portion of the build and are related to the python portion of things. The error specifies a missing python module but it builds fine for me locally with a standard maven build as well as a the very docker build being executed in travis. For now let's assume the problem is environmental/travis and not let it get in the way of the review. I'll keep trying to re-run the job periodically and see if i can get it to pass. [ Full content available at: https://github.com/apache/tinkerpop/pull/1245 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Commented] (TINKERPOP-2337) In upgrade guide for 3.4.2, the option RemoteConnection.PER_REQUEST_TIMEOUT does not exist
[
https://issues.apache.org/jira/browse/TINKERPOP-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036260#comment-17036260
]
ASF GitHub Bot commented on TINKERPOP-2337:
---
mmadoo commented on pull request #1246: TINKERPOP-2337 In upgrade guide for
3.4.2, the option RemoteConnection.PER_REQUEST_TIMEOUT does not exist
URL: https://github.com/apache/tinkerpop/pull/1246
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> In upgrade guide for 3.4.2, the option RemoteConnection.PER_REQUEST_TIMEOUT
> does not exist
> --
>
> Key: TINKERPOP-2337
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2337
> Project: TinkerPop
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.4.2, 3.4.3, 3.4.4, 3.4.5
>Reporter: Nicolas Trangosi
>Priority: Minor
>
> in the file {{docs/src/upgrade/release-3.4.x.asciidoc}} the sentence
> {{ List vertices = g.with(RemoteConnection.PER_REQUEST_TIMEOUT,
> 500).V().out("knows").toList()}}
> should be replaced by
> {{ List vertices = g.with(Tokens.ARGS_EVAL_TIMEOUT,
> 500L).V().out("knows").toList()}}
> Note: a Long should be used as argument instead of an integer else the
> following exception is thrown:
> {noformat}
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteConnection.getRequestOptions(DriverRemoteConnection.java:238)
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteConnection.submitAsync(DriverRemoteConnection.java:225)
> at
> org.apache.tinkerpop.gremlin.process.remote.traversal.step.map.RemoteStep.promise(RemoteStep.java:89)
> at
> org.apache.tinkerpop.gremlin.process.remote.traversal.step.map.RemoteStep.processNextStart(RemoteStep.java:65)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:128)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:38)
> at
> org.apache.tinkerpop.gremlin.process.traversal.Traversal.fill(Traversal.java:180)
> at
> org.apache.tinkerpop.gremlin.process.traversal.Traversal.toList(Traversal.java:118)
> {noformat}
> This option is only documented in upgrade guide, it could be useful to
> document all options in main documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2337) In upgrade guide for 3.4.2, the option RemoteConnection.PER_REQUEST_TIMEOUT does not exist
[
https://issues.apache.org/jira/browse/TINKERPOP-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036236#comment-17036236
]
Nicolas Trangosi commented on TINKERPOP-2337:
-
I will to try to prepare a pull request for these changes this week.
> In upgrade guide for 3.4.2, the option RemoteConnection.PER_REQUEST_TIMEOUT
> does not exist
> --
>
> Key: TINKERPOP-2337
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2337
> Project: TinkerPop
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.4.2, 3.4.3, 3.4.4, 3.4.5
>Reporter: Nicolas Trangosi
>Priority: Minor
>
> in the file {{docs/src/upgrade/release-3.4.x.asciidoc}} the sentence
> {{ List vertices = g.with(RemoteConnection.PER_REQUEST_TIMEOUT,
> 500).V().out("knows").toList()}}
> should be replaced by
> {{ List vertices = g.with(Tokens.ARGS_EVAL_TIMEOUT,
> 500L).V().out("knows").toList()}}
> Note: a Long should be used as argument instead of an integer else the
> following exception is thrown:
> {noformat}
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteConnection.getRequestOptions(DriverRemoteConnection.java:238)
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteConnection.submitAsync(DriverRemoteConnection.java:225)
> at
> org.apache.tinkerpop.gremlin.process.remote.traversal.step.map.RemoteStep.promise(RemoteStep.java:89)
> at
> org.apache.tinkerpop.gremlin.process.remote.traversal.step.map.RemoteStep.processNextStart(RemoteStep.java:65)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:128)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:38)
> at
> org.apache.tinkerpop.gremlin.process.traversal.Traversal.fill(Traversal.java:180)
> at
> org.apache.tinkerpop.gremlin.process.traversal.Traversal.toList(Traversal.java:118)
> {noformat}
> This option is only documented in upgrade guide, it could be useful to
> document all options in main documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (TINKERPOP-2192) Gremlin.Net.Driver.Connection.Parse throws a NullReferenceException
[
https://issues.apache.org/jira/browse/TINKERPOP-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036233#comment-17036233
]
Florian Hockmann edited comment on TINKERPOP-2192 at 2/13/20 1:50 PM:
--
No, not really, but this should really be a simple fix. So, if you want to
contribute, then this could be a good ticket to get started.
edit: Didn't see Stephen's comment yet when I wrote this.
was (Author: florian hockmann):
No, not really, but this should really be a simple fix. So, if you want to
contribute, then this could be a good ticket to get started.
> Gremlin.Net.Driver.Connection.Parse throws a NullReferenceException
> ---
>
> Key: TINKERPOP-2192
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2192
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.4.1
>Reporter: Florian Hockmann
>Priority: Minor
>
> The Parse method has only three objects on which we call methods of which two
> are {{readonly}}. So the problem is most likely in the error handling:
> {code}
> if (_callbackByRequestId.TryRemove(receivedMsg.RequestId, out var
> responseHandler))
> {
> responseHandler.HandleFailure(e);
> }
> {code}
> Here, {{responseHandler}} can be null if the callback handler for that
> request id was not found. So we just need a null check. (We can't notify
> anyone about a failure any way in this case.)
> Stack trace:
> {code}
> System.NullReferenceException: Object reference not set to an instance of an
> object.
>at Gremlin.Net.Driver.Connection.Parse(Byte[] received)
>at Gremlin.Net.Driver.Connection.ReceiveMessagesAsync()
>at Gremlin.Net.Driver.ProxyConnection.SubmitAsync[T](RequestMessage
> requestMessage)
>at Gremlin.Net.Driver.GremlinClient.SubmitAsync[T](RequestMessage
> requestMessage)
>at
> Gremlin.Net.Driver.Remote.DriverRemoteConnection.SubmitBytecodeAsync(Guid
> requestid, Bytecode bytecode)
>at
> Gremlin.Net.Driver.Remote.DriverRemoteConnection.SubmitAsync[S,E](Bytecode
> bytecode)
>at Gremlin.Net.Process.Remote.RemoteStrategy.ApplyAsync[S,E](ITraversal`2
> traversal)
>at Gremlin.Net.Process.Traversal.DefaultTraversal`2.ApplyStrategiesAsync()
>at
> Gremlin.Net.Process.Traversal.DefaultTraversal`2.Promise[TReturn](Func`2
> callback)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2192) Gremlin.Net.Driver.Connection.Parse throws a NullReferenceException
[
https://issues.apache.org/jira/browse/TINKERPOP-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036233#comment-17036233
]
Florian Hockmann commented on TINKERPOP-2192:
-
No, not really, but this should really be a simple fix. So, if you want to
contribute, then this could be a good ticket to get started.
> Gremlin.Net.Driver.Connection.Parse throws a NullReferenceException
> ---
>
> Key: TINKERPOP-2192
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2192
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.4.1
>Reporter: Florian Hockmann
>Priority: Minor
>
> The Parse method has only three objects on which we call methods of which two
> are {{readonly}}. So the problem is most likely in the error handling:
> {code}
> if (_callbackByRequestId.TryRemove(receivedMsg.RequestId, out var
> responseHandler))
> {
> responseHandler.HandleFailure(e);
> }
> {code}
> Here, {{responseHandler}} can be null if the callback handler for that
> request id was not found. So we just need a null check. (We can't notify
> anyone about a failure any way in this case.)
> Stack trace:
> {code}
> System.NullReferenceException: Object reference not set to an instance of an
> object.
>at Gremlin.Net.Driver.Connection.Parse(Byte[] received)
>at Gremlin.Net.Driver.Connection.ReceiveMessagesAsync()
>at Gremlin.Net.Driver.ProxyConnection.SubmitAsync[T](RequestMessage
> requestMessage)
>at Gremlin.Net.Driver.GremlinClient.SubmitAsync[T](RequestMessage
> requestMessage)
>at
> Gremlin.Net.Driver.Remote.DriverRemoteConnection.SubmitBytecodeAsync(Guid
> requestid, Bytecode bytecode)
>at
> Gremlin.Net.Driver.Remote.DriverRemoteConnection.SubmitAsync[S,E](Bytecode
> bytecode)
>at Gremlin.Net.Process.Remote.RemoteStrategy.ApplyAsync[S,E](ITraversal`2
> traversal)
>at Gremlin.Net.Process.Traversal.DefaultTraversal`2.ApplyStrategiesAsync()
>at
> Gremlin.Net.Process.Traversal.DefaultTraversal`2.Promise[TReturn](Func`2
> callback)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2192) Gremlin.Net.Driver.Connection.Parse throws a NullReferenceException
[
https://issues.apache.org/jira/browse/TINKERPOP-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036227#comment-17036227
]
Stephen Mallette commented on TINKERPOP-2192:
-
I don't think anyone is actively working on this one at the moment. If you'd
like to offer a pull request to fix it, I'm sure committers would be happy to
review. As of right now, given the Affects Version, a PR should target the
3.4-dev branch. Thanks.
> Gremlin.Net.Driver.Connection.Parse throws a NullReferenceException
> ---
>
> Key: TINKERPOP-2192
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2192
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.4.1
>Reporter: Florian Hockmann
>Priority: Minor
>
> The Parse method has only three objects on which we call methods of which two
> are {{readonly}}. So the problem is most likely in the error handling:
> {code}
> if (_callbackByRequestId.TryRemove(receivedMsg.RequestId, out var
> responseHandler))
> {
> responseHandler.HandleFailure(e);
> }
> {code}
> Here, {{responseHandler}} can be null if the callback handler for that
> request id was not found. So we just need a null check. (We can't notify
> anyone about a failure any way in this case.)
> Stack trace:
> {code}
> System.NullReferenceException: Object reference not set to an instance of an
> object.
>at Gremlin.Net.Driver.Connection.Parse(Byte[] received)
>at Gremlin.Net.Driver.Connection.ReceiveMessagesAsync()
>at Gremlin.Net.Driver.ProxyConnection.SubmitAsync[T](RequestMessage
> requestMessage)
>at Gremlin.Net.Driver.GremlinClient.SubmitAsync[T](RequestMessage
> requestMessage)
>at
> Gremlin.Net.Driver.Remote.DriverRemoteConnection.SubmitBytecodeAsync(Guid
> requestid, Bytecode bytecode)
>at
> Gremlin.Net.Driver.Remote.DriverRemoteConnection.SubmitAsync[S,E](Bytecode
> bytecode)
>at Gremlin.Net.Process.Remote.RemoteStrategy.ApplyAsync[S,E](ITraversal`2
> traversal)
>at Gremlin.Net.Process.Traversal.DefaultTraversal`2.ApplyStrategiesAsync()
>at
> Gremlin.Net.Process.Traversal.DefaultTraversal`2.Promise[TReturn](Func`2
> callback)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2019) Gremlin.Net.Driver.WebSocketConnection throws System.InvalidOperationException
[
https://issues.apache.org/jira/browse/TINKERPOP-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036224#comment-17036224
]
Stephen Mallette commented on TINKERPOP-2019:
-
Are you using CosmosDB [~idzmitry]? If so, I think you can see from the
comments that [~Florian Hockmann] struggled for a long time to reproduce this.
If we were to reopen this issue I think we'd need support from CosmosDB folks
for anything at all to happen with it. If you have reproduction steps for
making this happen with Gremlin Server by itself then we might have chance at
fixing it independently.
> Gremlin.Net.Driver.WebSocketConnection throws System.InvalidOperationException
> --
>
> Key: TINKERPOP-2019
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2019
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.3.3
> Environment: Azure App Service
>Reporter: Sami
>Priority: Critical
>
> We're getting the following {{System.InvalidOperationException}} error
> message:
> {code:c#}
> "There is already one outstanding 'SendAsync' call for this WebSocket
> instance. ReceiveAsync and SendAsync can be called simultaneously, but at
> most one outstanding operation for each of them is allowed at the same time.
> Problem Id:
> System.InvalidOperationException at
> Gremlin.Net.Driver.WebSocketConnection+d__5.MoveNext"{code}
>
> We get this exception sporadically and only a few times out of thousands.
> Unfortunately we have not been able to reproduce it.
>
> I understand that when dealing with web sockets, it is allowed to have only
> a single pending "send" or a single pending "receive".
>
> After looking at GitHub's WebSocketConnection class, I don't see any
> orchestration between SendMessageAsync's {{_client.SendAsync}} (currently
> line 54) and ReceiveMessageAsync's {{_client.ReceiveAsync}} (currently line
> 66).
>
> Reference Link:
>
> [https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/WebSocketConnection.cs]
>
> I'm wondering if not having orchestration in the WebSocketConnection class
> to keep the single pending "send" or a single pending "receive" rule may be
> the cause.
>
> In our .NET Core web api application, we create the GremlinConnection as a
> singleton in Startup.cs and then have one central call that makes Gremlin
> calls; i.e. it's a very straightforward implementation.
>
> Startup.cs:
> {code:c#}
> public void ConfigureServices(IServiceCollection services)
> {
> //...other stuff removed for brevity
> services.AddSingleton();
> }{code}
>
> Reader.cs:
> {code:c#}
> public async Task> ExecuteGremlinQuery(string
> query)
> {
> try
> {
> return await _gremlinConnection.Client.SubmitAsync(query);
> }
> catch (Gremlin.Net.Driver.Exceptions.ResponseException responseException)
> {
> //our error handling removed for brevity!
> }
> }{code}
>
> We use the Gremlin.Net version 3.3.3 nuget package and the
> Microsoft.NETCore.App SDK
>
> Would it be possible to identify if this is indeed a bug on Gremlin.NET?
> And if it is, any thoughts on a best-practice (temporary) work-around that
> we can implement?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2337) In upgrade guide for 3.4.2, the option RemoteConnection.PER_REQUEST_TIMEOUT does not exist
[
https://issues.apache.org/jira/browse/TINKERPOP-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036220#comment-17036220
]
Stephen Mallette commented on TINKERPOP-2337:
-
That's odd. I wonder why that was written that way. I can't find any reference
in time to when that token was on {{RemoteConnection}}. Usually, we consider
upgrade documentation static and historical, but in this case it just seems
wrong so I think a correction is in order. Since the upgrade notes are on
3.4.2, I think the correct token is actually:
{{Tokens.ARGS_SCRIPT_EVAL_TIMEOUT}}. It appears to only have been deprecated at
3.3.9 (and thus 3.4.4):
https://github.com/apache/tinkerpop/blob/3.4.4/gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/driver/Tokens.java#L62
and replaced with {{Tokens.ARGS_EVAL_TIMEOUT}} at that point. So, I'd say we
want two fixes here:
1. 3.4.2 upgrade docs should specify {{Tokens.ARGS_SCRIPT_EVAL_TIMEOUT}}
2. As you suggested the main reference documentation should make some mention
of the {{with(Tokens, value)}} syntax. I would say that it should probably just
go at the end of the "Connecting" section:
http://tinkerpop.apache.org/docs/current/reference/#_connecting
[~trangosi] did you intend to submit a pull request for these changes? if so, I
think we can forego changes to 3.3.-dev and the PR can simply target the
3.4-dev branch.
> In upgrade guide for 3.4.2, the option RemoteConnection.PER_REQUEST_TIMEOUT
> does not exist
> --
>
> Key: TINKERPOP-2337
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2337
> Project: TinkerPop
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.4.2, 3.4.3, 3.4.4, 3.4.5
>Reporter: Nicolas Trangosi
>Priority: Minor
>
> in the file {{docs/src/upgrade/release-3.4.x.asciidoc}} the sentence
> {{ List vertices = g.with(RemoteConnection.PER_REQUEST_TIMEOUT,
> 500).V().out("knows").toList()}}
> should be replaced by
> {{ List vertices = g.with(Tokens.ARGS_EVAL_TIMEOUT,
> 500L).V().out("knows").toList()}}
> Note: a Long should be used as argument instead of an integer else the
> following exception is thrown:
> {noformat}
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteConnection.getRequestOptions(DriverRemoteConnection.java:238)
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteConnection.submitAsync(DriverRemoteConnection.java:225)
> at
> org.apache.tinkerpop.gremlin.process.remote.traversal.step.map.RemoteStep.promise(RemoteStep.java:89)
> at
> org.apache.tinkerpop.gremlin.process.remote.traversal.step.map.RemoteStep.processNextStart(RemoteStep.java:65)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:128)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:38)
> at
> org.apache.tinkerpop.gremlin.process.traversal.Traversal.fill(Traversal.java:180)
> at
> org.apache.tinkerpop.gremlin.process.traversal.Traversal.toList(Traversal.java:118)
> {noformat}
> This option is only documented in upgrade guide, it could be useful to
> document all options in main documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [tinkerpop] spmallette opened pull request #1245: Tinkerpop 2338
https://issues.apache.org/jira/browse/TINKERPOP-2338 wip [ Full content available at: https://github.com/apache/tinkerpop/pull/1245 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
Re: Language constructs for listing running queries and cancelling them
Hi Jeff, thanks for your inquiry. There has not been much more discussion on this issue that I can recall, though recently improvements are being made into cancelling sessions which would effectively cancel a long run query: https://issues.apache.org/jira/browse/TINKERPOP-2336 I'm not yet sure what impact this change will have to non-session and/or bytecode based queries, but perhaps there is an opportunity to make an easy improvement there too. > If not, is there interest in picking up this particular mantle? Depending on where TINKERPOP-2336 goes we'd really cover the most crucial use case here which is explicit cancellation of a query that's gone crazy. It's not as surgical as the approach suggested in this thread but between TINKERPOP-2336 and the server timeouts reliably cleaning up everything else, I think that what's basically required is pretty well covered. More advanced functionality like listing long run queries, cancelling them by some identifier, etc would be nice-to-haves imo, keeping in mind that Gremlin Server is really just a reference implementation for the Gremlin Server Protocol which graph providers like JanusGraph should either extend or implement themselves. That said, I think that the community never really got a proposal on this to consider. It was in the earliest stage of discussion, a discussion which just stopped. I think my questions from before still stand but perhaps with a current twist...What exact features are proposed? How will they work in relation to TINKERPOP-2336? Will new client APIs be needed or can this work within the context of what we already have? and so on. > Would it make sense to file a TinkerPop ticket, or is an implementation proposal needed first? We try to reserve ticket creation until we've come to some consensus on what it is we're doing and we do that here on the dev list. Let's see where this thread goes and then we'll know what tickets should be created if any. > To develop an implementation proposal, it would help to know what related information is currently exposed on the server (e.g., are running queries listed in any central internal datastructures?). There is no list of running queries. Queries come in and are queued internally in the netty pipeline and are handed to the GremlinExecutor (in some fashion or another depending on a script or a session or bytecode or whatever - that's a bit of an annoyance and probably could/should be streamlined - Divij suggested this a while back - but it's a non-trivial refactoring i think). Here's the code for the GremlinExecutor: https://github.com/apache/tinkerpop/blob/b47812a6c522575c98a571061d058b1799dc7518/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/engine/GremlinExecutor.java the eval() methods return CompletableFuture objects which the netty constructs can use to try to interrupt those executions. You can find the netty handlers here: https://github.com/apache/tinkerpop/tree/b47812a6c522575c98a571061d058b1799dc7518/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/handler Of important note would be the OpSelectorHandler and OpExecutorHandler where the "selector" chooses the "op" to use based on the incoming RequestMessage. The "executor" then calls that op. The ops can be found here: https://github.com/apache/tinkerpop/tree/b47812a6c522575c98a571061d058b1799dc7518/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op where and cover the three primary approaches to query execution in sessionless (i.e. standard), in session and bytecode (i.e. traversal/TraversalOpProcessor). HTTP is a whole separate beasthonestly i don't think we should even have that functionality as we don't recommend it and folks always try to use it rather than just writing Gremlin in their favorite programming language. Anyway, that business can be found here: https://github.com/apache/tinkerpop/blob/b47812a6c522575c98a571061d058b1799dc7518/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/handler/HttpGremlinEndpointHandler.java Please let me know if you have any further questions. On Thu, Feb 13, 2020 at 6:13 AM Jeff Lerman wrote: > My team is experimenting with JanusGraph and in that context we ran into > some situations where it would be handy to have exactly the kind of > functionality that is proposed here. Has there been any more discussion > since these emails (I realize this exchange is from over a year ago)? > > If not, is there interest in picking up this particular mantle? Would it > make sense to file a TinkerPop ticket, or is an implementation proposal > needed first? To develop an implementation proposal, it would help to know > what related information is currently exposed on the server (e.g., are > running queries listed in any central internal datastructures?). > > Thanks, > --Jeff Lerman > > On 2018/11/12 17:15:52, Stephen Mallette wrote: > > We don't currently support bytecode on HTTP, so that's an entirely
Re: Language constructs for listing running queries and cancelling them
My team is experimenting with JanusGraph and in that context we ran into some
situations where it would be handy to have exactly the kind of functionality
that is proposed here. Has there been any more discussion since these emails
(I realize this exchange is from over a year ago)?
If not, is there interest in picking up this particular mantle? Would it make
sense to file a TinkerPop ticket, or is an implementation proposal needed
first? To develop an implementation proposal, it would help to know what
related information is currently exposed on the server (e.g., are running
queries listed in any central internal datastructures?).
Thanks,
--Jeff Lerman
On 2018/11/12 17:15:52, Stephen Mallette wrote:
> We don't currently support bytecode on HTTP, so that's an entirely other
> conversation - one I believe that we've had before. HTTP is not something
> TinkerPop tends to recommend so I personally wouldn't want to see us plow
> any resources into writing more code for HTTP. We largely just have HTTP
> for historical reasons going back to the days of Rexster. After some
> thought I'm not against asymmetry for bytecode based requests I don't think.
>
> As for next steps, I'd say that there needs to be a proposal for how this
> gets implemented in Gremlin Server and what changes to the protocol are
> needed for it to happen. As for the client-side API, I'm not sure I'm
> feeling very positive about the suggestion to do g.Q() or similar syntax
> because it doesn't have meaning outside of remote requests. That part can
> be discussed further once we know more about how the server will allow for
> interrupting traversals.
>
>
>
>
>
> On Fri, Nov 9, 2018 at 12:28 AM kARTHIK R wrote:
>
> > Yes, scoping this to bytecode is a good idea. Is there any risks in trying
> > to support this for HTTP requests? (Supporting sessions and scripts may
> > easily bloat up the scope. so your concern there is very valid).
> >
> > Either way, what would be the next steps to take this forward?
> >
> > Karthik
> >
> > On Wed, Nov 7, 2018 at 9:07 AM Stephen Mallette
> > wrote:
> >
> > > I like the thought for explicit cancellation, but I think that before we
> > > get into what that would look like or how it would work, we'd need to
> > > determine the scope of what we wanted to allow cancellation of. We have
> > > scripts (both with and without a session) and we have bytecode based
> > > requests. I suppose the scope could be such that we only attempted to
> > > cancel bytecode based traversals which is what your proposal reads like.
> > > That might be acceptable since we are trying to move folks away from
> > > scripts. This would be another feature that makes bytecode a better
> > choice
> > > over scripts. Any thoughts on having some asymmetry there?
> > >
> > > On Tue, Nov 6, 2018 at 3:26 PM kARTHIK R wrote:
> > >
> > > > Hi Team,
> > > >
> > > > This is a followup of a SO discussion[1] with Stephen where I wanted to
> > > see
> > > > if we can add language constructs for 1) Listing running queries 2)
> > > > Cancelling a running query. Something straightforward would look like
> > > this:
> > > >
> > > > g.query() or g.Q() -> Iterator for all running queries
> > > > g.query("132" or g.Q("123") -> project a single query
> > > > g.query("123").cancel() or g.Q("123").cancel() -> to cancel the query
> > > >
> > > > Later, the same can be extended with .profile() and other statistics
> > > steps.
> > > > Interested in hearing your thoughts.
> > > >
> > > > Karthik R
> > > >
> > > > [1]
> > > >
> > > >
> > >
> > https://stackoverflow.com/questions/53053463/how-do-i-list-running-gremlin-queries-how-can-i-cancel-slow-or-long-running-que
> > > >
> > >
> >
>
Re: [DISCUSS] release 3.4.6
Thanks for starting the discussion. It's a good thing that it was identified so quickly, I think we should tackle this asap to affect the least amount of users and providers. 1. yes. 2. review/merge and then immediate VOTE. I think we shouldn't wait for other potential issues. On Wed, Feb 12, 2020 at 10:25 PM Stephen Mallette wrote: > To my recollection we haven't released with a bug that made me think about > immediately re-releasing a patch since 2011, but it looks like 3.4.5 has > something not so nice in it. It was brought to light on gremlin-users today > and I created this JIRA for it: > > https://issues.apache.org/jira/browse/TINKERPOP-2338 > > While the bug has a workaround it's not nice and existing Gremlin matching > that pattern will immediately stop behaving properly on upgrade. Given that > the bug is related to graph mutations I find that a bit high on the > worrisome scale. > > I suppose the good news is that we learned about the problem quickly before > a ton of new code went to 3.4-dev and there is a fix that is surgical and > touches very little code. So, we could reasonably get this change through > review, merge it to 3.4-dev, create 3.4.6 artifacts and prepare for VOTE. I > don't see the need for a week long code freeze - we just skip to release > VOTE. > > So, I suppose the points for discussion here are: > > 1. Is the bug bad enough to warrant an immediate release of 3.4.6 (note > 3.3.11 is unaffected)? > 2. If so, are we good with a quick review/merge and an immediate build of a > 3.4.6 artifact for VOTE or should we perhaps take a bit more time to see if > other bad news comes in? >
