[
https://issues.apache.org/jira/browse/TINKERPOP3-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14980900#comment-14980900
]
Zachary Kurey commented on TINKERPOP3-932:
------------------------------------------
+1 to [~rjbriody]'s comment. Seems reasonable they need to figure out the
state, but stopping the current executing script is definitely less burdensome
then having to potentially redo a lot of work associated with previous script
submissions for the same session id.
As far as the scope of what the user or a client application needs to determine
what the current state is. I'm wondering if there is some kind of feedback
mechanism that could be added here as well(if it doesn’t already exist), where
the client could retrieve the last line of the latest script executed
associated with a particular session id? Then at least there is a clear way to
know how far the script made it.
> 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)
