Skip to content
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

Open
BenjaminYong opened this issue May 13, 2024 · 0 comments
Open

goroutine leaks when using subscriptions #796

BenjaminYong opened this issue May 13, 2024 · 0 comments
Labels
internally-reviewed Internally reviewed

Comments

@BenjaminYong
Copy link
Contributor

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.
image

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

goroutine profile: total 25605
25343 @ 0x43d9ee 0x44dda5 0xf34a98 0x46fda1
#	0xf34a97	github.com/wundergraph/graphql-go-tools/pkg/subscription.(*Handler).handleKeepAlive+0x97	/home/vsts/go/pkg/mod/github.com/wundergraph/graphql-go-tools/pkg/subscription/legacy_handler.go:387

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.

315 @ 0x43d9ee 0x408c45 0x408897 0xdada86 0x46fda1
#	0xdada85	github.com/wundergraph/graphql-go-tools/pkg/engine/datasource/graphql_datasource.(*gqlWSConnectionHandler).readBlocking+0x1e5	/home/vsts/go/pkg/mod/github.com/wundergraph/graphql-go-tools/pkg/engine/datasource/graphql_datasource/graphql_ws_handler.go:110

I'll raise a PR shortly with the suggested fixes for this.

Thanks,
Benny

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 jensneuse added the internally-reviewed Internally reviewed label May 21, 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
Labels
internally-reviewed Internally reviewed
Projects
None yet
Development

No branches or pull requests

2 participants