[
https://issues.apache.org/jira/browse/TINKERPOP3-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998982#comment-14998982
]
Dylan Millikin commented on TINKERPOP3-932:
-------------------------------------------
Wanted to get the ball rolling on this one again.
It seems to be the general consensus that the responsibility for the state
falls onto the user cencelling. So maybe we can orient the discussion towards
what should be covered by the feature:
Should {{cancel}} revert the bindings back to what they were? This option is
probably the most practical but it adds another behavior the users will need to
be knowledgeable about. In essence it reverts some stuff back but not
everything, this could be counter-intuitive.
Or should it simply force a "timeout" like behavior on the script? In this case
the user is responsible for the entire state when they cancel. This has the
advantage of being easy to understand since it works like a timeout. On the
other hand the bindings could/will be a mess.
> 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)
