[
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)
