[
https://issues.apache.org/jira/browse/TINKERPOP3-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14980266#comment-14980266
]
Dylan Millikin commented on TINKERPOP3-932:
-------------------------------------------
Just as extra info for [~zackurey]. There is also a way to close a remote
session (not just on the client end). This is recent so I thought I would point
it out.
(http://tinkerpop.incubator.apache.org/docs/3.0.2-SNAPSHOT/#_opprocessors_arguments
under SessionOpProcessor) I don't know if gremlin-driver already uses this,
I'd have to check.
Of course this doesn't help much in this particular case.
In principle it could be a nice feature to have. From an API point of view it
would make sense to have this be another {{key}}? (like say "cancel" or
"terminate" or something). People can use it if they want and others are free
to completely ignore it.
As for some of the tricky parts which kind of turn me off the idea. There's a
limit regarding what can be rolled back. Some edge cases I can think of:
- The goal is to keep session variables and such but what happens to everything
set during the "cancelled" script? Like bindings, variables, transaction
consumers, etc... and anything global really. I don't think there's a way to
reliably bring the state back to what it was before the script was executed?
- If multiple clients connect to a same session. If by any means one client
terminates what it considers to be a long running script it could be difficult
to debug (from the pov of other clients). Even though this is more of a user
responsibility it's still something to keep in mind.
I somehow think that terminating the session and reopening one client side is
the way to go. It implies that the burden of recreating the same session is put
on the client but I don't find that so shocking. In that aspect it's kind of
like how TP provides some fail-retry strategies but clients have to implement
their own anyways.
> 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)
