[
https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046854#comment-17046854
]
ASF GitHub Bot commented on TINKERPOP-2336:
-------------------------------------------
spmallette commented on pull request #1255: TINKERPOP-2336 Added
getMaxWaitForClose java driver setting.
URL: https://github.com/apache/tinkerpop/pull/1255
https://issues.apache.org/jira/browse/TINKERPOP-2336
Deprecated the "close" message for sessions along with its driver setting.
The driver should stay compatible with older server versions, but the server
now closes sessions with the close of the connection and there no longer is a
block while all messages return from the server after a `Client.close()`.
All tests pass with `docker/build.sh -t -n -i`
VOTE +1
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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)
