-
Notifications
You must be signed in to change notification settings - Fork 126
-
Notifications
You must be signed in to change notification settings - Fork 126
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
goroutine leaks when using subscriptions #796
Labels
internally-reviewed
Internally reviewed
Comments
BenjaminYong
added a commit
to BenjaminYong/graphql-go-tools
that referenced
this issue
May 13, 2024
BenjaminYong
added a commit
to BenjaminYong/graphql-go-tools
that referenced
this issue
May 14, 2024
jensneuse
pushed a commit
that referenced
this issue
Jun 4, 2024
) Hi team, Please see the suggested fixes to address the issue I raised: #796 After this change, the websocket handlers and their goroutines are closing as expected. As a result, my memory usage is much more lower and no longer leaking. ![image](https://github.com/wundergraph/graphql-go-tools/assets/53241741/b2a6667f-6fc7-48f4-b20f-afd2fdca2220) Thanks, Benny Co-authored-by: Aenimus <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi team,
Appreciate that v2 is out and that this is a bug in v1 graphql-go-tools. But thought I'd raise an issue and PR to address it for anyone using v1 still.
I've been noticing memory leaks in our federation application and have found the source of the issues when using pprof to profile the application.
Leak in handleKeepAlive
I was able to see a growing number in goroutines for the handleKeepAlive function which sends the KA message to the websockets. This function is used everytime a new subscription is started. Currently, this does not stop even when stopping the subscription/WebSocket or closing the GraphiQL browser tab. Hence, causes a leak everytime a subscription is run
Leak in readBlocking
Additionally, I found another source for growing goroutines in readBlocking. This function is used every time a new client is initiated. In its current state, if the WebSocket connection was closed, the function could block indefinitely when trying to send to errCh or dataCh if there were no receivers. This could lead to goroutines leaking and the program using more memory over time.
I'll raise a PR shortly with the suggested fixes for this.
Thanks,
Benny
The text was updated successfully, but these errors were encountered: