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