Skip to content

[SDK] BatchLogRecordProcessor still drains the queue in a tight loop, inconsistent with BatchSpanProcessor fix #4498

Description

@yswdqz

Describe your environment

  • Platform: macOS
  • opentelemetry-cpp version: main branch
  • Component: sdk/src/logs/batch_log_record_processor.cc
  • BatchLogRecordProcessor configuration:
    • max_queue_size = 8192
    • max_export_batch_size = 2048
    • schedule_delay_millis = 5000

Steps to reproduce

  1. Configure BatchLogRecordProcessor with a LogRecordExporter that counts export calls and records per call.
  2. Produce log records at a constant rate (e.g. 5,000 logs/s) for 10 seconds.
  3. Observe the number of export requests and the average number of logs per request.
  4. Produce 50,000 log records without calling ForceFlush().

What is the expected behavior?

With max_export_batch_size = 2048, exports should be close to 2048 records each. After #4466, BatchSpanProcessor behaves this way: on a normal wakeup it exports at most one batch, and only ForceFlush() / Shutdown() drain the entire buffer.

BatchLogRecordProcessor should follow the same semantics.


What is the actual behavior?

BatchLogRecordProcessor::Export() still drains the whole buffer in a tight loop:

void BatchLogRecordProcessor::Export()
{
  do {
    bool notify_force_flush =
        synchronization_data_->is_force_flush_pending.exchange(false, std::memory_order_acq_rel);
    if (notify_force_flush) {
      num_records_to_export = buffer_.size();
    } else {
      num_records_to_export =
          buffer_.size() >= max_export_batch_size_ ? max_export_batch_size_ : buffer_.size();
    }
    // ... consume & export ...
  } while (true);
}

And the worker wakes up as soon as the buffer is non-empty:

synchronization_data_->cv.wait_for(lk, timeout, [this] {
  ...
  return !buffer_.empty();
});

Measured result

Metric Value
Logs produced 50,000
Export calls 2,332
Average batch size 21.4
Full batches (>=2048) 1
Tiny batches (<100) 2,331

The first export is 2048 records; every subsequent export in the same wakeup is ~20–25 records because the worker keeps draining the buffer instead of waiting for the next full batch.


Additional context

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingtriage/acceptedIndicates an issue or PR is ready to be actively worked on.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions