[ https://issues.apache.org/jira/browse/TINKERPOP-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17720998#comment-17720998 ]
ASF GitHub Bot commented on TINKERPOP-2944: ------------------------------------------- vkagamlyk commented on code in PR #2058: URL: https://github.com/apache/tinkerpop/pull/2058#discussion_r1188864810 ########## gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs: ########## @@ -175,6 +175,7 @@ private void HandleReceivedMessage(ResponseMessage<List<object>> receivedMsg) { responseHandler?.Finalize(status.Attributes); _callbackByRequestId.TryRemove(receivedMsg.RequestId.Value, out _); + _cancellationByRequestId.TryRemove(receivedMsg.RequestId.Value, out _); Review Comment: maybe it's better to move clearing of `_cancellationByRequestId` 2 lines higher to avoid leak when `responseHandler?.Finalize` failed? > 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)