Read max-message-batch-size vendor property for batch sizing#48214
Open
EldertGrootenboer wants to merge 21 commits intoAzure:mainfrom
Open
Read max-message-batch-size vendor property for batch sizing#48214EldertGrootenboer wants to merge 21 commits intoAzure:mainfrom
EldertGrootenboer wants to merge 21 commits intoAzure:mainfrom
Conversation
EldertGrootenboer
requested review from
a team and
skarri-microsoft
as code owners
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the Service Bus Java sender batching logic to enforce a hard 1 MB maximum batch size, aligning client-side behavior with broker enforcement when AMQP link max-message-size is overstated (notably Premium partitioned namespaces).
Changes:
- Introduces a 1 MB cap constant and applies it when computing effective batch sizing across batch creation and send/schedule pathways.
- Adds parameterized unit tests validating capping behavior when the link reports sizes above/below 1 MB and when user-specified batch options exceed the cap.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| sdk/servicebus/azure-messaging-servicebus/src/main/java/com/azure/messaging/servicebus/ServiceBusSenderAsyncClient.java | Adds MAX_BATCH_SIZE_BYTES and caps link-derived sizing in batch creation, scheduling, flux send batching, and the message collector. |
| sdk/servicebus/azure-messaging-servicebus/src/test/java/com/azure/messaging/servicebus/ServiceBusSenderAsyncClientTest.java | Adds parameterized tests to validate 1 MB cap behavior and option validation under both V1/V2 stacks. |
EldertGrootenboer
force-pushed
the
fix/servicebus-batch-size-cap-ICM51000000793879
branch
from
40a0fac to
2cb1714
Compare
EldertGrootenboer
force-pushed
the
fix/servicebus-batch-size-cap-ICM51000000793879
branch
from
2cb1714 to
8de6ada
Compare
The Service Bus broker enforces a 1 MB batch size limit regardless of the max-message-size advertised on the AMQP link. Premium partitioned namespaces advertise 100 MB on the link, causing tryAddMessage() to accept batches the broker will reject. Cap batch creation in ServiceBusSenderAsyncClient.createMessageBatch() at 1 MB (MAX_BATCH_SIZE_BYTES). This is the single enforcement point: both sendMessages(iterable) and scheduleMessages(iterable) call createMessageBatch internally. Single-message paths (sendMessage, scheduleMessage) are NOT capped since the 1 MB limit is batch-specific and individual messages on Premium can validly exceed 1 MB up to the per-entity limit. When a user requests a batch size exceeding 1 MB via CreateMessageBatchOptions, throw ServiceBusException. Tracking: azure-service-bus#708 ICM: 51000000793879
EldertGrootenboer
force-pushed
the
fix/servicebus-batch-size-cap-ICM51000000793879
branch
from
8de6ada to
e3b2ef6
Compare
…to fix/servicebus-batch-size-cap-ICM51000000793879
…to fix/servicebus-batch-size-cap-ICM51000000793879
…to fix/servicebus-batch-size-cap-ICM51000000793879
- Add AmqpConstants.MAX_MESSAGE_BATCH_SIZE for com.microsoft:max-message-batch-size - Add AmqpSendLink.getMaxBatchSize() default method (falls back to getLinkSize()) - Override in ReactorSender to read vendor property from link remote properties - ServiceBusSenderAsyncClient.createMessageBatch() uses getMaxBatchSize() instead of getLinkSize(), with 1 MB fallback when vendor property is absent - Single-message paths (sendMessage, scheduleMessage) continue using getLinkSize() - 6 new ReactorSenderTest tests for vendor property, fallback, and edge cases - 2 new ServiceBusSenderAsyncClientTest tests for asymmetry and vendor property - Bump azure-core-amqp dependency to 2.12.0-beta.1 - Add CHANGELOG entry under Bugs Fixed
EldertGrootenboer
changed the title
Replace Flux.fromStream(IntStream...) with Flux.range().map() so the publisher remains resubscribable. Stream instances are single-use; if the code under test re-subscribes (retry, tracing instrumentation), the second subscription would fail with 'stream has already been operated upon or closed'.
skarri-microsoft
approved these changes
May 8, 2026
EldertGrootenboer
added a commit
to Azure/azure-sdk-for-js
that referenced
this pull request
May 8, 2026
…ch sizing (#38049) ## Problem On Premium large-message Service Bus entities, the AMQP link's `max-message-size` can be up to 100 MB, but the broker enforces a 1 MB limit for batch sends. The JS SDK reads `max-message-size` (via `this.link.maxMessageSize`) for batch sizing, so `createMessageBatch()` accepts batches up to 100 MB that the broker then rejects. Related: [azure-service-bus#708](Azure/azure-service-bus#708) ## Fix Read the `com.microsoft:max-message-batch-size` vendor property from the AMQP sender link attach frame, which correctly reports 256 KB (Standard) / 1 MB (Premium) independent of entity-level `max-message-size`. When the vendor property is absent (older service versions), fall back to `Math.min(maxMessageSize, defaultMaxBatchSize)` where `defaultMaxBatchSize` is 1 MB — this caps the batch size to prevent using the raw `max-message-size` (which can be up to 100 MB on Premium large-message entities). ### Changes - **`messageSender.ts`**: Add `defaultMaxBatchSize` constant (1 MB); add `getMaxBatchSizeFromLink()` that reads the vendor property from `this.link.properties`, falling back to `Math.min(maxMessageSize, defaultMaxBatchSize)`; update `createBatch()` to use the new method - **`messageSender.spec.ts`**: Unit tests for vendor property present, absent (with 1 MB cap), undefined properties, wrong type, zero value, user override, rejection of oversized `maxSizeInBytes`, Standard tier ### Cross-SDK alignment | SDK | Status | |-----|--------| | .NET | [PR #57941](Azure/azure-sdk-for-net#57941) | | Java | [PR #48214](Azure/azure-sdk-for-java#48214) | | Go | [PR #26530](Azure/azure-sdk-for-go#26530) | | Python | [PR #46197](Azure/azure-sdk-for-python#46197) | --------- Co-authored-by: Eldert Grootenboer (from Dev Box) <egrootenboer@microsoft.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
The Service Bus broker enforces a batch size limit (256 KB on Standard, 1 MB on Premium) that differs from the
max-message-sizeadvertised on the AMQP link. On Premium large-message entities, the gateway advertises up to 100 MB formax-message-size, but the batch limit remains 1 MB — causingtryAddMessage()to accept oversized batches that the broker then rejects.The service now advertises the correct batch limit via the vendor property
com.microsoft:max-message-batch-sizeon the sender link. This PR updates the SDK to read that property instead of hardcoding.Changes
azure-core-amqp:
AmqpConstants.MAX_MESSAGE_BATCH_SIZEsymbol forcom.microsoft:max-message-batch-sizeAmqpSendLink.getMaxBatchSize()default method (backward-compatible — falls back togetLinkSize()for Event Hubs)ReactorSenderto read the vendor property from link remote properties, with fallback tomax-message-sizewhen absentReactorSenderTesttests: vendor property reading, absent/non-numeric/zero fallbacks, caching, asymmetryazure-messaging-servicebus:
ServiceBusSenderAsyncClient.createMessageBatch()now callsgetMaxBatchSize()instead ofgetLinkSize()sendMessage,scheduleMessage) unchanged — continue using fullmax-message-sizeDEFAULT_MAX_BATCH_SIZE_BYTES(1 MB) as last-resort fallback when both properties are unavailableBehavior by tier
max-message-sizemax-message-batch-sizeICM Reference
ICM 51000000793879 — customer on Premium tier partitioned, Java SDK 7.17.14,
tryAddMessage()accepted >2 MB batch, broker rejected.