You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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: