[
https://issues.apache.org/jira/browse/TINKERPOP-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2944.
---------------------------------------
Fix Version/s: 3.7.0
3.5.7
3.6.4
Resolution: Fixed
> 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
> Fix For: 3.7.0, 3.5.7, 3.6.4
>
>
> 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)
