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

Streams leak memory #36

Closed
KennethL opened this issue Jan 4, 2021 · 2 comments
Closed

Streams leak memory #36

KennethL opened this issue Jan 4, 2021 · 2 comments

Comments

@KennethL
Copy link

KennethL commented Jan 4, 2021

grpcbox version v0.11.0
The grpcbox library leaks memory for each message sent on an open stream. In the stream_state record used for the h2_stream gen_statem data, there is an incoming_frames field. This field is a queue to which frames are added, but none are ever removed. In fact the information in this field is not used, apart from adding to it. Because of adding more and more data to it, the memory usage will keep increasing as long as the stream stays open. Note that currently the chatterbox library used by grpcbox is a forked one, not the original one.

@tsloughter
Copy link
Owner

Quick note on here about chatterbox fork. I haven't merged my changed into upstream chatterbox because I want full reviews of any change and those have been hard to come by, joedevivo/chatterbox#127

If I could get help with reviewing it'll make upstreaming (I have permissions to merge into the main chatterbox repo) quicker.

@tsloughter
Copy link
Owner

It looks like this setup "works fine" for certain usages, like using http2 as http1.1 where you just do a request and then read a response when the stream ends -- so should also be fine for unary grpc calls?

I'm going to do a quick fix where the stream is just told to not store the response since it doesn't need to when streaming data back to the client right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants