[jira] [Created] (TINKERPOP-2945) TextP.regex() Serialization Failing in Java driver
Yang Xia created TINKERPOP-2945:
---
Summary: TextP.regex() Serialization Failing in Java driver
Key: TINKERPOP-2945
URL: https://issues.apache.org/jira/browse/TINKERPOP-2945
Project: TinkerPop
Issue Type: Bug
Components: driver
Affects Versions: 3.6.3, 3.7.0
Reporter: Yang Xia
The serialization for TextP.regex() is failing in Java for both GraphBinary and
GraphSON.
To reproduce, add
{code:java}
new Object[] {"TextP", TextP.regex("^meh"), null}, {code}
into the argument list for GraphBinaryReaderWriterRoundTripTest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2810) gremlinpython aiohttp dependency requirement too strict
[ https://issues.apache.org/jira/browse/TINKERPOP-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720661#comment-17720661 ] ASF GitHub Bot commented on TINKERPOP-2810: --- Cole-Greer commented on PR #1958: URL: https://github.com/apache/tinkerpop/pull/1958#issuecomment-1538993249 @curtiscook In case you haven't seen it yet [TinkerPop 3.6.3 has now been released](https://twitter.com/apachetinkerpop/status/1655615767881056256). > gremlinpython aiohttp dependency requirement too strict > --- > > Key: TINKERPOP-2810 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2810 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.6.1 >Reporter: Gunther Vogel >Assignee: Stephen Mallette >Priority: Major > Fix For: 3.7.0 > > > Currently, the requirements specify aiohttp >= 3.8.0, <= 3.8.1, disallowing > newer bugfix releases of aiohttp (current version is 3.8.3). Following the > general semantic versioning rules, the upper bound should be <4.0.0 (disallow > breaking changes). > The current requirements are the result of TINKERPOP-2668 which only had the > goal of avoiding the bug contained in versions <= 3.7.4. > Fixing aiohttp at a non-current bugfix release step increases the maintenance > effort needed to get an error-free overall library setup; in my case, > gremlinpython is not even used directly, but just pulled in by awswrangler. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2703) Build on JDK17
[
https://issues.apache.org/jira/browse/TINKERPOP-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720647#comment-17720647
]
ASF GitHub Bot commented on TINKERPOP-2703:
---
lyndonbauto commented on code in PR #2056:
URL: https://github.com/apache/tinkerpop/pull/2056#discussion_r1187780194
##
tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerGraph.java:
##
@@ -103,9 +103,9 @@ public final class TinkerGraph implements Graph {
protected TinkerIndex vertexIndex = null;
protected TinkerIndex edgeIndex = null;
-protected final IdManager vertexIdManager;
-protected final IdManager edgeIdManager;
-protected final IdManager vertexPropertyIdManager;
+protected IdManager vertexIdManager;
+protected IdManager edgeIdManager;
+protected IdManager vertexPropertyIdManager;
Review Comment:
Is the removal of `final` here required?
> Build on JDK17
> --
>
> Key: TINKERPOP-2703
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2703
> Project: TinkerPop
> Issue Type: Improvement
> Components: build-release
>Affects Versions: 3.5.2
>Reporter: Stephen Mallette
>Priority: Minor
>
> Upgrade the build to work with JDK17. This actually is a bit of an umbrella
> issue covering lots of different things in TinkerPop. Early examination of
> this issue shows that like the move to JDK11, the change is not trivial.
> Known issues so far:
> * Groovy 4.x upgrade brings some strange failures to the gmavenplus-plugin
> during GLV building
> * Kryo 3.x is not compliant with JDK17
> In addition, Please look at the related linked issues for more information.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (TINKERPOP-2943) GraphBinary serialization error when vertex ID is larger than 2**31.
[
https://issues.apache.org/jira/browse/TINKERPOP-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720641#comment-17720641
]
Matthew Carr edited comment on TINKERPOP-2943 at 5/8/23 6:34 PM:
-
I tested your suggestion, and using `long` does indeed resolve the issue. This
is a good work-around, but may I suggest that during serialization an integer
type is chosen based on the size of the Python `int` which is being serialized.
So if the value falls with in the 32-bit signed range it's serialized as it is
now, but if it's outside this range and inside the 64-bit signed range, it's
serialized as a long. If an `int` falls outside of the 64-bit range, then an
exception occurs. Do you think this makes sense?
was (Author: JIRAUSER300219):
I tested your suggestion, and using `long` does indeed resolve the issue. This
is a good work-around, but may I suggest that during serialization an integer
type is chosen based on the size of the Python `int` which is being serialized.
So if the value falls with in the 32-bit signed range it's serialized as it is
now, but if it's outside this range and inside the 64-bit signed range, it's
serialized as a long. If an `int` that falls outside of the 64-bit range, then
an exception occurs. Do you think this makes sense?
> GraphBinary serialization error when vertex ID is larger than 2**31.
>
>
> Key: TINKERPOP-2943
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2943
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.6.2
> Environment: Python 3.10
>Reporter: Matthew Carr
>Priority: Major
>
> An exception occurs when using the "graphbinaryV1" serialization format and
> an attempt is made to query a vertex whose ID is larger than `2**31`. I
> encountered this issue on `gremlinpython` 3.6.2 running on Python 3.10. A
> minimal reproduction is as follows:
> ```
> from gremlin_python.driver.driver_remote_connection import
> DriverRemoteConnection
> from gremlin_python.process.anonymous_traversal import traversal
> remote = DriverRemoteConnection("ws://127.0.0.1:8182/gremlin", "g")
> g = traversal().withRemote(remote)
> g.V(2**31 + 1).next()
> ```
> This code produces the following stack trace on my machine:
> ```
> Traceback (most recent call last):
> File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
> return _run_code(code, main_globals, None,
> File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
> exec(code, run_globals)
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/__main__.py",
> line 39, in
> cli.main()
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py",
> line 430, in main
> run()
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py",
> line 284, in run_file
> runpy.run_path(target, run_name="__main__")
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 321, in run_path
> return _run_module_code(code, init_globals, run_name,
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 135, in _run_module_code
> _run_code(code, mod_globals, init_globals,
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 124, in _run_code
> exec(code, run_globals)
> File "/home/matt/Projects/tada/thermo/repro.py", line 6, in
> g.V(2**31 + 1).next()
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 117, in next
> return self.__next__()
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 48, in __next__
> self.traversal_strategies.apply_strategies(self)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 684, in apply_strategies
> traversal_strategy.apply(traversal)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/remote_connection.py",
> line 78, in apply
> remote_traversal = self.remote_connection.submit(traversal.bytecode)
> File
>
[jira] [Comment Edited] (TINKERPOP-2943) GraphBinary serialization error when vertex ID is larger than 2**31.
[
https://issues.apache.org/jira/browse/TINKERPOP-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720641#comment-17720641
]
Matthew Carr edited comment on TINKERPOP-2943 at 5/8/23 6:34 PM:
-
I tested your suggestion, and using `long` does indeed resolve the issue. This
is a good work-around, but may I suggest that during serialization an integer
type is chosen based on the size of the Python `int` which is being serialized.
So if the value falls with in the 32-bit signed range it's serialized as it is
now, but if it's outside this range and inside the 64-bit signed range, it's
serialized as a long. If an `int` falls outside of the 64-bit signed range,
then an exception occurs. Do you think this makes sense?
was (Author: JIRAUSER300219):
I tested your suggestion, and using `long` does indeed resolve the issue. This
is a good work-around, but may I suggest that during serialization an integer
type is chosen based on the size of the Python `int` which is being serialized.
So if the value falls with in the 32-bit signed range it's serialized as it is
now, but if it's outside this range and inside the 64-bit signed range, it's
serialized as a long. If an `int` falls outside of the 64-bit range, then an
exception occurs. Do you think this makes sense?
> GraphBinary serialization error when vertex ID is larger than 2**31.
>
>
> Key: TINKERPOP-2943
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2943
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.6.2
> Environment: Python 3.10
>Reporter: Matthew Carr
>Priority: Major
>
> An exception occurs when using the "graphbinaryV1" serialization format and
> an attempt is made to query a vertex whose ID is larger than `2**31`. I
> encountered this issue on `gremlinpython` 3.6.2 running on Python 3.10. A
> minimal reproduction is as follows:
> ```
> from gremlin_python.driver.driver_remote_connection import
> DriverRemoteConnection
> from gremlin_python.process.anonymous_traversal import traversal
> remote = DriverRemoteConnection("ws://127.0.0.1:8182/gremlin", "g")
> g = traversal().withRemote(remote)
> g.V(2**31 + 1).next()
> ```
> This code produces the following stack trace on my machine:
> ```
> Traceback (most recent call last):
> File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
> return _run_code(code, main_globals, None,
> File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
> exec(code, run_globals)
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/__main__.py",
> line 39, in
> cli.main()
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py",
> line 430, in main
> run()
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py",
> line 284, in run_file
> runpy.run_path(target, run_name="__main__")
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 321, in run_path
> return _run_module_code(code, init_globals, run_name,
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 135, in _run_module_code
> _run_code(code, mod_globals, init_globals,
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 124, in _run_code
> exec(code, run_globals)
> File "/home/matt/Projects/tada/thermo/repro.py", line 6, in
> g.V(2**31 + 1).next()
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 117, in next
> return self.__next__()
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 48, in __next__
> self.traversal_strategies.apply_strategies(self)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 684, in apply_strategies
> traversal_strategy.apply(traversal)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/remote_connection.py",
> line 78, in apply
> remote_traversal = self.remote_connection.submit(traversal.bytecode)
> File
>
[jira] [Commented] (TINKERPOP-2943) GraphBinary serialization error when vertex ID is larger than 2**31.
[
https://issues.apache.org/jira/browse/TINKERPOP-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720641#comment-17720641
]
Matthew Carr commented on TINKERPOP-2943:
-
I tested your suggestion, and using `long` does indeed resolve the issue. This
is a good work-around, but may I suggest that during serialization an integer
type is chosen based on the size of the Python `int` which is being serialized.
So if the value falls with in the 32-bit signed range it's serialized as it is
now, but if it's outside this range and inside the 64-bit signed range, it's
serialized as a long. If an `int` that falls outside of the 64-bit range, then
an exception occurs. Do you think this makes sense?
> GraphBinary serialization error when vertex ID is larger than 2**31.
>
>
> Key: TINKERPOP-2943
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2943
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.6.2
> Environment: Python 3.10
>Reporter: Matthew Carr
>Priority: Major
>
> An exception occurs when using the "graphbinaryV1" serialization format and
> an attempt is made to query a vertex whose ID is larger than `2**31`. I
> encountered this issue on `gremlinpython` 3.6.2 running on Python 3.10. A
> minimal reproduction is as follows:
> ```
> from gremlin_python.driver.driver_remote_connection import
> DriverRemoteConnection
> from gremlin_python.process.anonymous_traversal import traversal
> remote = DriverRemoteConnection("ws://127.0.0.1:8182/gremlin", "g")
> g = traversal().withRemote(remote)
> g.V(2**31 + 1).next()
> ```
> This code produces the following stack trace on my machine:
> ```
> Traceback (most recent call last):
> File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
> return _run_code(code, main_globals, None,
> File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
> exec(code, run_globals)
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/__main__.py",
> line 39, in
> cli.main()
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py",
> line 430, in main
> run()
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py",
> line 284, in run_file
> runpy.run_path(target, run_name="__main__")
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 321, in run_path
> return _run_module_code(code, init_globals, run_name,
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 135, in _run_module_code
> _run_code(code, mod_globals, init_globals,
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 124, in _run_code
> exec(code, run_globals)
> File "/home/matt/Projects/tada/thermo/repro.py", line 6, in
> g.V(2**31 + 1).next()
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 117, in next
> return self.__next__()
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 48, in __next__
> self.traversal_strategies.apply_strategies(self)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 684, in apply_strategies
> traversal_strategy.apply(traversal)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/remote_connection.py",
> line 78, in apply
> remote_traversal = self.remote_connection.submit(traversal.bytecode)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/driver_remote_connection.py",
> line 104, in submit
> result_set = self._client.submit(bytecode,
> request_options=self._extract_request_options(bytecode))
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/client.py",
> line 150, in submit
> return self.submit_async(message, bindings=bindings,
> request_options=request_options).result()
> File "/usr/lib/python3.10/concurrent/futures/_base.py", line 458, in result
> return self.__get_result()
> File
[jira] [Commented] (TINKERPOP-2703) Build on JDK17
[ https://issues.apache.org/jira/browse/TINKERPOP-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720567#comment-17720567 ] ASF GitHub Bot commented on TINKERPOP-2703: --- xiazcy commented on code in PR #2056: URL: https://github.com/apache/tinkerpop/pull/2056#discussion_r1187609968 ## docs/src/upgrade/release-3.7.x.asciidoc: ## @@ -146,6 +146,24 @@ See: link:https://issues.apache.org/jira/browse/TINKERPOP-2819[TINKERPOP-2819] distributions. Any app which makes use of both `gremlin-driver` and `gremlin-server` will now need to directly include both modules. + Building and Running with JDK 17 Review Comment: Should we also add a section in the developer doc section for this? ## docs/src/upgrade/release-3.7.x.asciidoc: ## @@ -146,6 +146,24 @@ See: link:https://issues.apache.org/jira/browse/TINKERPOP-2819[TINKERPOP-2819] distributions. Any app which makes use of both `gremlin-driver` and `gremlin-server` will now need to directly include both modules. + Building and Running with JDK 17 Review Comment: Should we also add a section in the developer doc for this? > Build on JDK17 > -- > > Key: TINKERPOP-2703 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2703 > Project: TinkerPop > Issue Type: Improvement > Components: build-release >Affects Versions: 3.5.2 >Reporter: Stephen Mallette >Priority: Minor > > Upgrade the build to work with JDK17. This actually is a bit of an umbrella > issue covering lots of different things in TinkerPop. Early examination of > this issue shows that like the move to JDK11, the change is not trivial. > Known issues so far: > * Groovy 4.x upgrade brings some strange failures to the gmavenplus-plugin > during GLV building > * Kryo 3.x is not compliant with JDK17 > In addition, Please look at the related linked issues for more information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2944) Memory leak in Gremlin.Net driver if CancellationToken is used
[
https://issues.apache.org/jira/browse/TINKERPOP-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann updated TINKERPOP-2944:
Description:
We have noticed in my team at G DATA that a .NET service has been using an
increasing amount of memory since we began to propagate the
{{CancellationToken}} into the Gremlin.Net traversal executions which was
introduced in TINKERPOP-2794.
We could track this down with memory profiling to [this place in the
driver|https://github.com/apache/tinkerpop/blob/5c8af70c7fac3ee98df36d250b05320e67ff1b96/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L94]
where we register a callback to execute when cancellation is requested. These
registered callbacks are only cleaned up when the whole {{Connection}} object
gets disposed. Since the callback contains a reference to the full
{{RequestMessage}} of the traversal, it can contain a lot of data. This is
something that I've completely overlooked when I added support for cancellation.
The driver should clean up those callbacks when they are not needed any more
because the request has been processed completely (either successfully or with
an error).
was:
We have noticed in my team at G DATA that a .NET service has been using an
increasing amount of memory since we began to propagate the
{{CancellationToken}} into the Gremlin.Net traversal executions which was
introduced in TINKERPOP-2794.
We could track this down with memory profiling to [this place in the
driver|https://github.com/FlorianHockmann/tinkerpop/blob/5c8af70c7fac3ee98df36d250b05320e67ff1b96/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L94]
where we register a callback to execute when cancellation is requested. These
registered callbacks are only cleaned up when the whole {{Connection}} object
gets disposed. Since the callback contains a reference to the full
{{RequestMessage}} of the traversal, it can contain a lot of data. This is
something that I've completely overlooked when I added support for cancellation.
The driver should clean up those callbacks when they are not needed any more
because the request has been processed completely (either successfully or with
an error).
> Memory leak in Gremlin.Net driver if CancellationToken is used
> --
>
> Key: TINKERPOP-2944
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2944
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.6.2, 3.5.5, 3.6.3, 3.5.6
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
>
> We have noticed in my team at G DATA that a .NET service has been using an
> increasing amount of memory since we began to propagate the
> {{CancellationToken}} into the Gremlin.Net traversal executions which was
> introduced in TINKERPOP-2794.
> We could track this down with memory profiling to [this place in the
> driver|https://github.com/apache/tinkerpop/blob/5c8af70c7fac3ee98df36d250b05320e67ff1b96/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L94]
> where we register a callback to execute when cancellation is requested.
> These registered callbacks are only cleaned up when the whole {{Connection}}
> object gets disposed. Since the callback contains a reference to the full
> {{RequestMessage}} of the traversal, it can contain a lot of data. This is
> something that I've completely overlooked when I added support for
> cancellation.
> The driver should clean up those callbacks when they are not needed any more
> because the request has been processed completely (either successfully or
> with an error).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2944) Memory leak in Gremlin.Net driver if CancellationToken is used
Florian Hockmann created TINKERPOP-2944:
---
Summary: Memory leak in Gremlin.Net driver if CancellationToken is
used
Key: TINKERPOP-2944
URL: https://issues.apache.org/jira/browse/TINKERPOP-2944
Project: TinkerPop
Issue Type: Bug
Components: dotnet
Affects Versions: 3.5.5, 3.6.2, 3.6.3, 3.5.6
Reporter: Florian Hockmann
Assignee: Florian Hockmann
We have noticed in my team at G DATA that a .NET service has been using an
increasing amount of memory since we began to propagate the
{{CancellationToken}} into the Gremlin.Net traversal executions which was
introduced in TINKERPOP-2794.
We could track this down with memory profiling to [this place in the
driver|https://github.com/FlorianHockmann/tinkerpop/blob/5c8af70c7fac3ee98df36d250b05320e67ff1b96/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L94]
where we register a callback to execute when cancellation is requested. These
registered callbacks are only cleaned up when the whole {{Connection}} object
gets disposed. Since the callback contains a reference to the full
{{RequestMessage}} of the traversal, it can contain a lot of data. This is
something that I've completely overlooked when I added support for cancellation.
The driver should clean up those callbacks when they are not needed any more
because the request has been processed completely (either successfully or with
an error).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
