Open verdie-g opened 1 month ago
In common scenario when all signals are enabled, 3 threads are created by OTel - BatchExportProcessor for Traces. BatchExportProcessor for Logs, PeriodicReader for Metrics, each creates own thread that sits idle for 99% of the time.
Package
OpenTelemetry
Is your feature request related to a problem?
BatchExportProcessor is unnecessarily spawning a thread for the export. This thread spends 99% of its time blocked. This is a little waste of resource and it can also mislead investigations about thread pool starvation (a blocked thread looks like an issue until you find out it's not a thread pool thread).
What is the expected behavior?
The export spends its time waiting for a trigger or for the response of the export operation. It is completely fine using the .NET thread pool as long as all operations are asynchronous. This would make OTEL a better citizen in the .NET ecosystem.
The work would be:
Which alternative solutions or features have you considered?
N/A
Additional context
No response