Repository navigation
[BUG] EventHubBufferedProducerClient: maxWaitTime is restarted by every event, so partial batches are delayed until full #50921
Description
Describe the bug
EventDataAggregator builds its timer as Flux.switchOnNext(eventSink.map(e -> Flux.interval(maxWaitTime))), so
every enqueued event restarts the timer. It behaves like an idle/debounce timer: as long as events for a partition
arrive more often than maxWaitTime, the timer never fires and a batch is only published once it is full by size.
The Javadoc of EventHubBufferedProducerClientBuilder.maxWaitTime(Duration) says:
The amount of time to wait for a batch to be built with events in the buffer before publishing a partially full batch.
Observed
maxWaitTime= 250 ms, 6 partitions, ~1 KB events.- ~100 events/s total → end-to-end latency ~1 s.
- ~250 events/s total (~42 events/s per partition) → latency ~30 s, i.e. the time to fill a 1 MB batch
(~1,240 events) — higher load gives dramatically higher latency.
Expected behavior
A partially full batch is published at most maxWaitTime after its first event was added, regardless of how fast
further events arrive.
To Reproduce
Enqueue events to one partition at an interval shorter than maxWaitTime (e.g. every 50 ms with maxWaitTime 250 ms)
and observe that nothing is sent until the batch is full. Regression test pushesBatchAfterMaxTimeWhileEventsKeepArriving
in the linked PR.
Setup
- Java 17, azure-messaging-eventhubs 5.21.6 (same code on main as of 2026-10-21)
Activity
github-actions commentedon Oct 22, 2026
🎯 Agentic Issue Triage
Summary:
EventDataAggregatorrestarts itsmaxWaitTimetimer on every enqueued event (switchOnNext), so partial batches are delayed until full when events arrive faster thanmaxWaitTime.📋 Issue Details
Package:
com.azure:azure-messaging-eventhubs5.21.6Affected API:
EventDataAggregator,EventHubBufferedProducerClientBuilder.maxWaitTime(Duration)Scenarios:
Root ask: Publish a partial batch at most
maxWaitTimeafter its first event, per the Javadoc.🔎 Debugging / Reproduction Notes
The described timer behaves as a debounce/idle timer rather than a fixed deadline from the first event.
Suggested investigation steps:
EventDataAggregator.pushesBatchAfterMaxTimeWhileEventsKeepArriving.🏷️ Label Confidence
Client— data-plane SDK behaviorEvent Hubs— buffered producer client in azure-messaging-eventhubs👥 Owner Routing
# ServiceLabel: %Event Hubs(line 335) — service label matches%Mgmtcatch-all did not match because the category is Client.github-actions commentedon Oct 22, 2026
Thank you for your feedback. Tagging and routing to the team member(s) best able to assist.
//cc: Ashish Chhabria (@axisc) Eric Lam (MSFT) (@hmlam) Johnathan W (@j7nw4r) Josue Gomez (@SwayGom) Sagar Patel (@sagar0207) SJ (@sjkwak)