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 beast....honestly 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 <jeff.ler...@invitae.com.invalid> 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 <spmalle...@gmail.com> 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 <k4rth...@gmail.com> 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 <spmalle...@gmail.com> > > > 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 <k4rth...@gmail.com> 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 > > > > > > > > > > > > > > >
