[
https://issues.apache.org/jira/browse/TINKERPOP-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
