[jira] [Comment Edited] (TINKERPOP3-932) Add ability to cancel script execution associated with a Gremlin Server Session

["Dylan Millikin (JIRA)" <ji...@apache.org>]

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

Dylan Millikin edited comment on TINKERPOP3-932 at 10/29/15 1:26 PM:
---------------------------------------------------------------------

Ah you're right I didn't think about that case. I was also wondering if what I had brought up wasn't already the case when an exception is thrown? For instance :

{code}
g.addV()
g.tx().commit()
g.V().stepDoesNotExist()
{code}

Would result in the same behavior right? This in theory could alleviate the shortcomings of a cancel feature so long as the cancel is treated like an exception? Responsibility falls back on the user.


was (Author: dmill):
Ah you're right I didn't think about that case. I was also wondering if what I had brought up wasn't already the case when an exception is thrown? For instance :

{code}
g.addV()
g.tx().commit()
g.V().stepDoesNotExist()
{code}

Would result in the same behavior right? This in theory could alleviate the shortcomings of a cancel feature so long as the cancel is treated like an exception?

> Add ability to cancel script execution associated with a Gremlin Server Session 
> --------------------------------------------------------------------------------
>
>                 Key: TINKERPOP3-932
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-932
>             Project: TinkerPop 3
>          Issue Type: Improvement
>          Components: server
>    Affects Versions: 3.0.2-incubating
>            Reporter: Zachary Kurey
>            Assignee: stephen mallette
>
> 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<ResultSet>}} 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)