-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Consider disallowing components from starting goroutines during creation #9734
Comments
I am in favor of this. Is there a way we can use |
Yes, your proposed test would be a great way to test this. In my mind, this should be something we test through |
Makes total sense to me to take that approach! 👍 |
This would help greatly, agreed. Thanks Curtis! |
@crobert-1 can you point me to the place where the Kafka exporter starts a goroutine in I suppose another way to fix this issue would be to introduce a |
Sorry the confusion there, it looks like this PR moved the goroutine start to I found a couple other examples, the k8s attributes processor (slightly different, but same idea), and the signalfx exporter:
(I still haven't done a full search of this, so this isn't a definitive list 👍) Edit:
|
Describe the bug
For context, here's the collector's component documentation, specifically referencing this section:
I've observed that some components are starting goroutines in the creation step. This can cause potential memory leaks and isn't clear to consumers. Here are my overarching points:
Shutdown
is not called on any created component. Component creation is called in the sub stack of this method, but if an error is returned no created components are shutdown.Create
starts background work, especially when step 2 of the referenced documentation isStart
. With unclear behavior we're liable to mistakenly assume things (such as it being unnecessary to callShutdown
ifStart
hasn't been called). The memory leak described in my first point is another case in point of this.I haven't found any place that requires goroutines to be started in creation, all could be started in
Start
.Steps to reproduce
The kafka exporter is an example of starting a running goroutine during
Create{Logs/Traces/Metrics}Exporter
. If any component created after this exporter in the process of building the service graph returns an error on Create, the collector will shutdown without callingShutdown
on the kafka exporter. This is a goroutine (memory) leak.What did you expect to see?
Create
creates a component, but nothing starts doing the work of the components untilStart
is called.What did you see instead?
Leaked goroutines unless
Shutdown
is called, even without callingStart
.Additional context
Another example of lack of clarity around components and
Shutdown
: #9682Alternative
We could call
Shutdown
on every created component if any single one fails, as a safeguard against goroutines started inCreate
. However, this still doesn't resolve the issue of clarity and expectations around what "Create" should do.The text was updated successfully, but these errors were encountered: