[OTLP] Synchronous requests for HTTP calls

[carlcamilleri]

Proposed changes to perform truly synchronous calls for the HTTP protocol in .NET Framework and .NET (Core) versions less than .NET 5

Fixes #
Targets to remove the "synch-over-async" anti-pattern within OtlExportClient, mandated by the use of HttpClient. The HttpClient version only supports truly synchronous calls from .NET 5 upwards .

This is only done for Otlp exporters over HTTP, since GRPC requests need HTTP/2, which is not supported except through the use of HttpClient.

Changes

The main changes are:

1. New method SendHttpRequestSynchronous in OtlpExportClient abstract class, that performs truly synchronous requests. This method avoids the use of HttpClient and instead uses the (obsolete) WebRequest.
2. The return data from this method is converted to an HttpResponseMessage via the new method CreateResponseFromWebResponse to retain compatibility with the return type of the existing SendHttpRequest method.
3. A new helper method CreateSynchronousRequestParams to build the arguments for SendHttpRequestSynchronous, equivalent to what is done in CreateHttpRequest.
4. Update of OtlpHttpExportClient such that CreateSynchronousRequestParams and SendHttpRequestSynchronous are used unless running under .NET 5.0 or upwards.

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[rajkumar-rangaraj]

Thank you for the contribution!

We appreciate the effort to improve the OTLP Exporter. However, we’d like to avoid introducing additional complexity or options into the core Send logic of the exporter. The current design intentionally relies on asynchronous operations for performance and scalability.

If there's a need to perform a synchronous export or customize the behavior (e.g., for testing or integration scenarios), the exporter already exposes an HttpClientFactory option, which can be leveraged to plug in custom HTTP handlers or logic as needed:
https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/src/OpenTelemetry.Exporter.OpenTelemetryProtocol#configure-httpclient

We recommend using that extensibility point to handle such custom scenarios without modifying the core exporter logic.

[carlcamilleri]

Hi @rajkumar-rangaraj thanks for the update.

I must say however that, from performance benchmarks, an application on .NET Framework 4.8 is currently exhibiting markedly slower throughput (~75% less throughput) when enabling OTEL tracing. It is also exhibiting random crashes, consistent with treadpool starvation that is hallmark behaviour of sync-over-async.

Would it perhaps help if I provide a .NET 4.8 MVP that replicates the scenario for further analysis and clarification?

Thanks

[rajkumar-rangaraj]

Hi @carlcamilleri, Thanks again for the detailed follow-up.

We’d like to avoid adding synchronous logic or new configuration options to the core OTLP exporter. Maintaining a single, async-first pathway helps us ensure long-term reliability and consistency across platforms.

That being said, we want to make sure your scenario is unblocked. If you could share a minimal reproducible example (MVP) that highlights the issue, we’d be happy to take a closer look and work with you on potential alternatives, such as using the HttpClientFactory extensibility point or other workarounds for .NET Framework-specific needs.

Thanks again for engaging with us on this — looking forward to your MVP.

[carlcamilleri]

Great thanks! I’ll provide that asap

[carlcamilleri]

Hello @rajkumar-rangaraj please find an MVP here: https://github.com/carlcamilleri/opentelemetry-dotnet-mvp/

In this case the application is barebones and therefore does not generate as much data as the production application (no database calls, for example), but toggling ON/OFF OTEL still results in ~11% drop in throughput:
https://github.com/carlcamilleri/opentelemetry-dotnet-mvp/tree/master/benchmarks

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or pushing will instruct the bot to automatically remove the label. This bot runs once per day.