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

Warn if materializer is not referenced any more but StreamSupervisor is still alive #23736

Open
jrudolph opened this issue Sep 27, 2017 · 3 comments
Labels
1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted discuss Tickets that need some discussion before proceeding. Not decided if it's a good idea. help wanted Issues that the core team will likely not have time to work on t:stream

Comments

@jrudolph
Copy link
Member

In "real", long-running apps, dropping the reference to the materializer is often a sign that you create too many one-off materializers without shutting them down again after use (potential memory leak).

I guess the StreamSupervisor could monitor a reference queue to see when this happens but it's hard to say if it will introduce spurious warnings.

@jrudolph jrudolph added 1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted help wanted Issues that the core team will likely not have time to work on discuss Tickets that need some discussion before proceeding. Not decided if it's a good idea. t:stream labels Sep 27, 2017
@jrudolph
Copy link
Member Author

jrudolph commented Oct 9, 2017

We could also automatically shut down the stream supervisor after the materializer went out of scope and all running streams were finished.

@richardimaoka
Copy link
Contributor

Wanted to see if I can work on this but not sure what to do for

StreamSupervisor could monitor a reference queue

and how to detect

the materializer went out of scope

Much appreciated if you could provide more pointers on this.

@patriknw
Copy link
Member

Weak references and such can have a negative impact on GC performance. I'm not sure if that is also true for a reference queue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted discuss Tickets that need some discussion before proceeding. Not decided if it's a good idea. help wanted Issues that the core team will likely not have time to work on t:stream
Projects
None yet
Development

No branches or pull requests

3 participants