You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered: