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