[
https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17337385#comment-17337385
]
Stephen Mallette commented on TINKERPOP-2336:
---------------------------------------------
yeah...that should have been removed in 3.5.0. i guess i'd not gotten to all
the drivers. it won't hurt anything to continue to send it but it is not really
relevant anymore. we should fix that for 3.5.1.
* TINKERPOP-2559 - .NET
* TINKERPOP-2560 - Python
* TINKERPOP-2561 - Javascript
> 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)
