Skip to content

feat(sdk-logs): add maxConcurrentExports to enable concurrent batch e…#8253

Open
TruongNguyen1305 wants to merge 1 commit intoopen-telemetry:mainfrom
TruongNguyen1305:improvement/BatchLogRecordProcessor/concurrent-export
Open

feat(sdk-logs): add maxConcurrentExports to enable concurrent batch e…#8253
TruongNguyen1305 wants to merge 1 commit intoopen-telemetry:mainfrom
TruongNguyen1305:improvement/BatchLogRecordProcessor/concurrent-export

Conversation

@TruongNguyen1305
Copy link
Copy Markdown
Contributor

Summary

This PR introduces a new configuration option maxConcurrentExports for BatchLogRecordProcessor to allow multiple export operations to run concurrently.

By enabling controlled parallelism, this change improves log export throughput under high load while maintaining backpressure.


Motivation

Currently, BatchLogRecordProcessor performs exports sequentially, allowing only a single in-flight export at any given time. While this simplifies flow control, it can become a bottleneck in high-throughput scenarios, especially when:

  • Export latency is non-trivial (e.g., network-bound OTLP exporters)
  • Log production rate exceeds single-threaded export capacity
  • The underlying exporter already supports asynchronous or multi-threaded execution

At the same time, switching to fully asynchronous export without limits can overwhelm downstream systems (e.g., OTLP receivers), leading to errors such as HTTP/2 REFUSED_STREAM.


Changes

  • Add a new configuration parameter:

    int maxConcurrentExports

  • Allow multiple export batches to be processed in parallel, bounded by maxConcurrentExports

  • Preserve existing behavior by default:

    • maxConcurrentExports = 1 (sequential export)

Design Considerations

Controlled Concurrency

Instead of unbounded async exports, this approach ensures:

  • Bounded number of in-flight export requests
  • Protection against overwhelming downstream systems
  • Stable behavior under burst traffic

Backpressure

When the concurrency limit is reached:

  • Additional batches will be processed synchronously
  • This maintains backpressure semantics similar to the current implementation

Executor Utilization

This change allows better utilization of the underlying LogRecordExporter, particularly when:

  • The exporter uses an internal ExecutorService
  • The exporter performs non-blocking or async I/O (e.g., OTLP over gRPC)

By enabling concurrent exports at the processor level, we avoid underutilizing available execution resources.


Compatibility

  • Default behavior remains unchanged (maxConcurrentExports = 1)
  • No breaking API changes
  • Fully backward compatible

@TruongNguyen1305 TruongNguyen1305 requested a review from a team as a code owner April 5, 2026 15:08
@codecov
Copy link
Copy Markdown

codecov bot commented Apr 5, 2026

Codecov Report

❌ Patch coverage is 23.33333% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.23%. Comparing base (207c861) to head (70fd8bb).

Files with missing lines Patch % Lines
...metry/sdk/logs/export/BatchLogRecordProcessor.java 20.00% 19 Missing and 1 partial ⚠️
...dk/logs/export/BatchLogRecordProcessorBuilder.java 40.00% 2 Missing and 1 partial ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main    #8253      +/-   ##
============================================
- Coverage     90.32%   90.23%   -0.10%     
- Complexity     7651     7653       +2     
============================================
  Files           842      842              
  Lines         23075    23103      +28     
  Branches       2312     2316       +4     
============================================
+ Hits          20842    20846       +4     
- Misses         1514     1537      +23     
- Partials        719      720       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@jack-berg
Copy link
Copy Markdown
Member

I'm sympathetic to the issues you're discussing the PR description, but the behavior of BatchLogRecordProcessor is bound by the spec: https://github.com/open-telemetry/opentelemetry-specification

The portion of the spec concerning BatchLogRecordProcessor contains normative language that explicitly prohibits calling export concurrently: https://github.com/open-telemetry/opentelemetry-specification/blame/083460ecc38dce5ed3b26ba142f2a2422c6f91e5/specification/logs/sdk.md#L537-L539

If you want to extend it with this type of capabilities, you'd have to work through the process to update the spec first.

Alternatively, you can create your own copy of BatchLogRecordProcessor and customize to suit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants