[ https://issues.apache.org/jira/browse/TINKERPOP-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17721954#comment-17721954 ]
ASF GitHub Bot commented on TINKERPOP-2944: ------------------------------------------- kenhuuu commented on PR #2058: URL: https://github.com/apache/tinkerpop/pull/2058#issuecomment-1544900944 VOTE +1 > 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)