[jira] [Commented] (TINKERPOP-2336) Allow close of channel without having to wait for server
[
https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17337396#comment-17337396
]
Florian Hockmann commented on TINKERPOP-2336:
-
Good to know. I'll submit a PR for .NET as the change is really trivial.
> 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)
[jira] [Commented] (TINKERPOP-2336) Allow close of channel without having to wait for server
[
https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (TINKERPOP-2336) Allow close of channel without having to wait for server
[
https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (TINKERPOP-2336) Allow close of channel without having to wait for server
[
https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2336) Allow close of channel without having to wait for server
[
https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052346#comment-17052346
]
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
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)
[jira] [Commented] (TINKERPOP-2336) Allow close of channel without having to wait for server
[
https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (TINKERPOP-2336) Allow close of channel without having to wait for server
[
https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (TINKERPOP-2336) Allow close of channel without having to wait for server
[
https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032383#comment-17032383
]
Stephen Mallette commented on TINKERPOP-2336:
-
It seems that currently we allow for more than one {{Client}} to connect to the
same session. I'm not sure what the value in that is, but it causes a bit of
trouble because with multiple channels bound to the same session the session
can't simply subscribe to the channel that created it to determine when it is
closed. it has to subscribe to any channel that interacts with it and then the
close of one {{Client}} in that situations gets sorta messy. Does the close of
one client mean kill it all? or do all clients have to close for the session to
be closed. Anyway, seems weird. I'm inclined to seal off that "feature" and
simply bind one {{Client}} to one session. It's not like the requests will
process in parallel or anything - they just end up queuing in the order
received and I don't think that use case makes particular sense for how we
perceive sessions to be used. I suppose that's a bit of a breaking change but
I'm not sure we need to classify it as such since we didn't really promote that
approach and I suppose such breaking functionality wouldn't appear until we
removed the deprecation of the close message which should.
> 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)
