[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] [Closed] (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:all-tabpanel
]
Stephen Mallette closed TINKERPOP-2336.
---
Fix Version/s: 3.4.7
3.3.11
3.5.0
Resolution: Done
As part of this ticket I also took the step to remove
{{maxWaitForSessionClose}} from 3.5.0 and removed driver functionality to send
the session "close" message and removed the server functionality to do anything
with that message besides return a {{NO_CONTENT}} back.
https://github.com/apache/tinkerpop/commit/89faefc50848e957348ee615d6c72496c0621b43
> 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] [Created] (TINKERPOP-2347) Remove invalid service descriptors from gremlin-shaded
Olivier Michallat created TINKERPOP-2347:
Summary: Remove invalid service descriptors from gremlin-shaded
Key: TINKERPOP-2347
URL: https://issues.apache.org/jira/browse/TINKERPOP-2347
Project: TinkerPop
Issue Type: Bug
Components: build-release
Affects Versions: 3.4.5
Reporter: Olivier Michallat
{{gremlin-shaded.jar}} contains a couple of service descriptors inherited from
Jackson:
{code}
META-INF/services/com.fasterxml.jackson.core.JsonFactory
META-INF/services/com.fasterxml.jackson.core.ObjectCodec
{code}
They still reference unshaded classes, for example in the first one:
{code}
com.fasterxml.jackson.core.JsonFactory
{code}
This creates a problem if the JAR is used as an automatic module in a JPMS
application. The module system tries to convert the files into {{provides}}
directives in the dynamically generated module descriptor, but it checks for
the existence of the types in the process:
{code}
Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for
/path/to/gremlin-shaded-3.4.5.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class
com.fasterxml.jackson.core.JsonFactory not in module
{code}
I didn't find a way to work around this error without modifying the JAR.
I think the best approach would be to filter out those files during the shading
process. They were wrong anyway, so it's unlikely that anyone will miss them.
--
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-2192) Gremlin.Net.Driver.Connection.Parse throws a NullReferenceException
[
https://issues.apache.org/jira/browse/TINKERPOP-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052310#comment-17052310
]
ASF GitHub Bot commented on TINKERPOP-2192:
---
spmallette commented on pull request #1247: TINKERPOP-2192 Null checks added to
Connection.Parse
URL: https://github.com/apache/tinkerpop/pull/1247
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
> Gremlin.Net.Driver.Connection.Parse throws a NullReferenceException
> ---
>
> Key: TINKERPOP-2192
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2192
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.4.1
>Reporter: Florian Hockmann
>Priority: Minor
>
> The Parse method has only three objects on which we call methods of which two
> are {{readonly}}. So the problem is most likely in the error handling:
> {code}
> if (_callbackByRequestId.TryRemove(receivedMsg.RequestId, out var
> responseHandler))
> {
> responseHandler.HandleFailure(e);
> }
> {code}
> Here, {{responseHandler}} can be null if the callback handler for that
> request id was not found. So we just need a null check. (We can't notify
> anyone about a failure any way in this case.)
> Stack trace:
> {code}
> System.NullReferenceException: Object reference not set to an instance of an
> object.
>at Gremlin.Net.Driver.Connection.Parse(Byte[] received)
>at Gremlin.Net.Driver.Connection.ReceiveMessagesAsync()
>at Gremlin.Net.Driver.ProxyConnection.SubmitAsync[T](RequestMessage
> requestMessage)
>at Gremlin.Net.Driver.GremlinClient.SubmitAsync[T](RequestMessage
> requestMessage)
>at
> Gremlin.Net.Driver.Remote.DriverRemoteConnection.SubmitBytecodeAsync(Guid
> requestid, Bytecode bytecode)
>at
> Gremlin.Net.Driver.Remote.DriverRemoteConnection.SubmitAsync[S,E](Bytecode
> bytecode)
>at Gremlin.Net.Process.Remote.RemoteStrategy.ApplyAsync[S,E](ITraversal`2
> traversal)
>at Gremlin.Net.Process.Traversal.DefaultTraversal`2.ApplyStrategiesAsync()
>at
> Gremlin.Net.Process.Traversal.DefaultTraversal`2.Promise[TReturn](Func`2
> callback)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [tinkerpop] spmallette commented on issue #1250: fix for https://issues.apache.org/jira/browse/TINKERPOP-2192
thanks @dzmitry-lahoda VOTE +1 - assuming changelog entry on merge. [ Full content available at: https://github.com/apache/tinkerpop/pull/1250 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
