[
https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17337364#comment-17337364
]
Florian Hockmann commented on TINKERPOP-2336:
---------------------------------------------
I just saw this issue linked in the upgrade docs which say:
{quote}TinkerPop drivers no longer send the session "close" message to kill a
session. The close of the connection itself should be responsible for the close
of the session.
{quote}
I think we forgot to also remove this functionality from the GLV drivers. At
least for Gremlin.Net, I still see that we send a message to close the session:
[https://github.com/apache/tinkerpop/blob/e71a7a9b68c318f54c17961c0c79828d7bbaff04/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L273]
Or is that something different?
> Allow close of channel without having to wait for server
> --------------------------------------------------------
>
> Key: TINKERPOP-2336
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2336
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
> Affects Versions: 3.3.10
> Reporter: Stephen Mallette
> Assignee: Stephen Mallette
> Priority: Major
> Labels: deprecation
> Fix For: 3.5.0, 3.3.11, 3.4.7
>
>
> The java driver hangs about waiting for results to return after a
> {{Client.close()}} is called. That creates problems if there is a desire to
> kill the client but there is a long run query on the server and that query is
> configured to an especially long timeout. I think there just needs to be a
> configuration for the amount of time the client will wait for results before
> just giving up and shutting down. A byproduct of this change is that by
> allowing the {{Client}} to close the channel while a query is executing
> creates a cancellation sort of functionality which should issue an interrupt
> to the traversal executing on the server.
> With this change in place it sort of creates a feature somewhat at odds with
> the session "close" message which tries to release a specific session. The
> problem with that message is that it really is only useful if there is not
> already a message ahead of it getting processed and stuck otherwise it is
> queued and won't be processed until the message ahead of it is handled.
> Obviously, if the goal is to kill the session because of a long run process
> then this feature becomes a bit unhelpful. If the close of the channel
> accomplishes the same thing as the close message then I think we would want
> to deprecate the close message and remove it for 3.5.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
