[
https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17034804#comment-17034804
]
Stephen Mallette commented on TINKERPOP-2336:
---------------------------------------------
These changes have required some thinking, but I have what I believe will be
the core of the PR to 3.3-dev here:
https://github.com/apache/tinkerpop/commit/4bd6a47abf9889e420427a660fe71a3f7866f78b
As things are set now, the driver will continue to send the "close" message
automatically and the server will still support it, however the introduction of
the {{maxWaitForClose}} configuration at least enables the driver to not block
while waiting for a reply to all messages in which case the close of the
connection can properly kill the server process (also now implemented on the
server).
Going forward, I think 3.4-dev behavior will remain unchanged. When this gets
to master i think we will simply remove the deprecated
{{maxWaitForSessionClose}} configuration, send the close message for backward
compatibility with older servers (no waiting for a response though), have the
server simply no-op handle the close operation and bind one session to one
connection. So, for 3.5.0 there would be full compatibility with old drivers
and new and some minor breaking behavior related to having more than one
connection per session which as mentioned in the previous comment doesn't seem
to make sense anyway.
> 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
>
> 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)
