-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Async activity inputs potential memory leak #2203
Comments
Thank you for the detailed reproduction. Running the provided code and looking at a memory snapshot it looks like the activity input is being held because the internal |
What are the tradeoffs of doing one over the other? |
From the user perspective very little. Either would remove the reference to the StateMachine and let the input be GC'd |
Is there a target version where this fix can be included? |
Yes I hope to have some improvements here for the next minor SDK release . |
When starting multiple async activities within a workflow, references to the activity inputs are never null’d out so the inputs are never garbage collected, leading to a memory leak. This has caused our workers to run out of memory.
Expected Behavior
The expectation/assumption is that as activities within a workflow complete, references to their inputs are null’d out, making them eligible for garbage collection.
Actual Behavior
After running the below code for a while, a heap dump shows that a strong reference to each activity input is held by the class
WorkflowOutboundCallsInterceptor$ActivityInput
, even after each activity completes, causing a memory leak.Steps to Reproduce the Problem
See below code for reproduction.
Specifications
The text was updated successfully, but these errors were encountered: