tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Mallette (Jira)" <j...@apache.org>
Subject [jira] [Commented] (TINKERPOP-2336) Allow close of channel without having to wait for server
Date Thu, 05 Mar 2020 20:21:00 GMT

    [ https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17052487#comment-17052487

Stephen Mallette commented on TINKERPOP-2336:

It's worth noting that in the process of the 3.5.0 changes I manually tested the prior version
of server/driver against 3.5.0 and ensured compatibility and expected behavior. 3.4.x/3.3.x
driver has no problem dealing with the modification to the 3.5.0 protocol around the now removed
session "close" message and 3.5.0 driver which no longer sends the "close" message works nicely
with the 3.3.x/3.4.x servers that still process that message. 

> 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

View raw message