Add documentation on computation load balancing via rabbitmq - #46
Add documentation on computation load balancing via rabbitmq#46freddidierRTE wants to merge 1 commit into
Conversation
|
Warning Review limit reached
Next review available in: 53 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (7)
📒 Files selected for processing (12)
📝 WalkthroughWalkthroughAdded GridSuite architecture documentation and diagrams. Updated README links to the new architecture files. Added request-routing documentation and RabbitMQ load-balancing guidance with supporting Draw.io diagrams. ChangesGridSuite architecture documentation
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Signed-off-by: freddidierRTE <frederic-f.didier@rte-france.com>
![coderabbitai[bot]](https://cdn.github.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@architecture/diagrams/BackendFrontend.drawio`:
- Line 10: Update the diagram labels in the relevant mxCell entries: change
“Librairies” to “Libraries”, “Dyna Mapping Server” to “Dynamic mapping server”,
and “Dynamic Margin Calculator Server” to “Dynamic margin calculation server”,
matching the names documented in MicroServices.md.
In `@architecture/diagrams/gridsuite_architecture.drawio`:
- Line 116: Update the edge labels in the diagram: change “ajust balance on CGM”
to “adjust balance on CGM” and change each “run / get resuts” label to “run /
get results,” including the occurrences associated with the visible edge cells
and the additional referenced locations.
In `@architecture/MicroServices.md`:
- Around line 219-223: Clarify the Gateway description’s “https” responsibility
to align with the SSL termination behavior documented in RequestRouting.md.
Update the security-features wording in the Gateway section to state whether TLS
is terminated by ingress or an external load balancer, or explicitly describe
the Gateway’s actual HTTPS role without implying it performs SSL termination.
In `@architecture/rabbitmq/rabbit-load-balancing.md`:
- Around line 122-125: Update the “Relevant issues” section in
rabbit-load-balancing.md to describe the Test Binder consumer-group limitation:
bindings in the same group may each process one published message instead of
distributing it. State that production RabbitMQ delivers the message to only one
consumer, and require validation through either a RabbitMQ integration test or a
test profile enabling only one binding.
- Around line 88-101: Require and show prefetch: 1 for every consumer binding in
the priority load-balancing documentation and all referenced diagram sites:
architecture/rabbitmq/rabbit-load-balancing.md lines 88-101,
architecture/rabbitmq/diagrams/load-balancing-solution.drawio lines 16-29 and
46-59, and architecture/rabbitmq/diagrams/load-balancing-solution.drawio lines
165-166. Clarify that a consumer is “busy” when blocked by at least one
unacknowledged delivery, preserving the one-message-per-server behavior
described by the priority assignments.
- Around line 108-120: Update architecture/rabbitmq/rabbit-load-balancing.md
lines 108-120 to document the supported RabbitMQ binding property
spring.cloud.stream.rabbit.bindings.<binding>.consumer.consumer-priority,
including a configuration example or an explicit version-dependent caveat;
clarify that YAML can configure x-priority and direct AMQP customization is not
always required. Update
architecture/rabbitmq/diagrams/load-balancing-solution.drawio lines 13-29 to
remove or revise the misleading “Spring Cloud Stream — Config” implication
consistently; no other sites require changes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: f61357b9-c387-4cbd-9168-1f57a5ea9052
⛔ Files ignored due to path filters (7)
architecture/diagrams/BackendFrontend.drawio.svgis excluded by!**/*.svgarchitecture/diagrams/RequestRouting.drawio.svgis excluded by!**/*.svgarchitecture/diagrams/RequestRoutingExample.drawio.svgis excluded by!**/*.svgarchitecture/diagrams/archi_gridsuite.pngis excluded by!**/*.pngarchitecture/diagrams/gridsuite_architecture.svgis excluded by!**/*.svgarchitecture/rabbitmq/diagrams/load-balancing-problem.drawio.svgis excluded by!**/*.svgarchitecture/rabbitmq/diagrams/load-balancing-solution.drawio.svgis excluded by!**/*.svg
📒 Files selected for processing (12)
README.mdarchitecture/Architecture.mdarchitecture/CommonLibraries.mdarchitecture/MicroServices.mdarchitecture/RequestRouting.mdarchitecture/diagrams/BackendFrontend.drawioarchitecture/diagrams/RequestRouting.drawioarchitecture/diagrams/RequestRoutingExample.drawioarchitecture/diagrams/gridsuite_architecture.drawioarchitecture/rabbitmq/diagrams/load-balancing-problem.drawioarchitecture/rabbitmq/diagrams/load-balancing-solution.drawioarchitecture/rabbitmq/rabbit-load-balancing.md
| RabbitMQ's [`x-priority`](https://www.rabbitmq.com/docs/consumer-priority#how-to-use) parameter allows consumers to be assigned a priority. When a message arrives, RabbitMQ dispatches it to the **highest-priority available consumer**. | ||
|
|
||
| **Priority assignment per server instance:** | ||
|
|
||
| | Consumer | Priority | | ||
| |----------|----------| | ||
| | `consumeRun3` | 3 (highest) | | ||
| | `consumeRun2` | 2 | | ||
| | `consumeRun1` | 1 | | ||
| | `consumeRun0` | 0 (lowest) | | ||
|
|
||
| Each server instance has one consumer at each priority level. Since `consumeRun3` (priority 3) is available on every server, incoming messages are spread across all servers before any server gets a second message. | ||
|
|
||
| **Result:** A server only gets a second message once every other server already has at least one message running. No idle servers while one is overloaded. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== files =="
git ls-files | rg '(^|/)rabbit-load-balancing\.md$|load-balancing-solution\.drawio$' || true
echo "== markdown section =="
cat -n architecture/rabbitmq/rabbit-load-balancing.md | sed -n '1,150p'
echo "== drawio relevant sections =="
cat -n architecture/rabbitmq/diagrams/load-balancing-solution.drawio | sed -n '1,90p;155,175p'
echo "== prefetch/priority mentions =="
rg -n "prefetch|x-priority|consumer priority|priority" architecture/rabbitmq rabbitmq || trueRepository: gridsuite/documentation
Length of output: 50380
🌐 Web query:
RabbitMQ consumer priority x-priority maximum concurrency blocked consumer prefetch
💡 Result:
In RabbitMQ, consumer priorities, prefetch settings, and consumer blocking interact to control how messages are distributed among multiple consumers [1][2]. Consumer Priority (x-priority) You can assign a priority to a consumer by setting the x-priority argument to an integer value during the basic.consume method call [1][3]. Consumers without an explicit priority are assigned a priority of 0 [1]. Higher integer values indicate higher priority [1]. When multiple consumers are active, RabbitMQ prioritizes delivery to consumers with the highest priority [1][2]. Interaction with Prefetch (Blocked Consumers) The prefetch count (configured via basic.qos) limits the number of unacknowledged messages a consumer can have at any given time [4][5]. When a high-priority consumer reaches its prefetch limit, it becomes blocked from receiving further messages until it acknowledges at least one of its current deliveries [1][2][5]. Once the high-priority consumer is blocked, RabbitMQ will begin delivering messages to consumers with lower priority [1][2]. It is important to note that RabbitMQ does not wait for a high-priority consumer to become unblocked if there is an active lower-priority consumer available [1][2]. Concurrency Considerations RabbitMQ does not enforce a specific "maximum concurrency" limit for consumers in the way it does for connections or channels [6]. Instead, consumer concurrency is typically managed by the client application's architecture (e.g., thread pools or worker pools) [7]. While some client libraries allow you to control the degree of concurrency in their internal dispatching logic, applications that require strict message ordering or specific concurrency levels should handle this coordination within their own code or by limiting the number of consumers and their respective prefetch counts [7]. In summary, to effectively use these features together: 1. Assign x-priority to your consumers to define the order of delivery preference [1]. 2. Use basic.qos to set a prefetch limit on consumers, which prevents any single consumer from hoarding messages and allows lower-priority consumers to receive work when high-priority consumers reach their capacity [2][4][5]. 3. Ensure your application architecture handles the desired level of concurrent message processing, as RabbitMQ primarily controls the delivery flow via prefetch and priority, not by managing your application's internal thread concurrency [7].
Citations:
- 1: https://www.rabbitmq.com/docs/consumer-priority
- 2: https://www.rabbitmq.com/docs/next/consumers
- 3: https://www.rabbitmq.com/docs/4.2/consumer-priority
- 4: https://www.rabbitmq.com/docs/consumer-prefetch
- 5: https://www.rabbitmq.com/docs/next/confirms
- 6: https://www.rabbitmq.com/docs/next/limits
- 7: https://www.rabbitmq.com/docs/4.2/consumers
🌐 Web query:
RabbitMQ priority consumers dispatch order when high priority consumer has unacknowledged messages prefetch
💡 Result:
In RabbitMQ, consumer priorities allow you to ensure that high-priority consumers receive messages whenever they are active, while lower-priority consumers only receive messages when the high-priority consumers are blocked [1][2]. A consumer is considered "blocked" when it cannot accept more messages, most commonly because its channel has reached the configured prefetch limit (via basic.qos) due to outstanding unacknowledged messages [1][2]. When a high-priority consumer becomes blocked due to its prefetch limit, RabbitMQ will begin dispatching messages to lower-priority consumers that are active [1][2]. Crucially, RabbitMQ does not wait for a blocked high-priority consumer to become unblocked if there is an active lower-priority consumer ready to accept work; the broker will prioritize keeping message flow active by sending messages to the lower-priority consumer [1][2]. Once the high-priority consumer acknowledges its outstanding messages, it is no longer blocked and will resume its status as the preferred recipient. Consequently, RabbitMQ will return to dispatching messages to the high-priority consumer, and the lower-priority consumer will stop receiving messages (assuming it is not also needed to handle excess volume) [1][2]. In summary, the prefetch setting acts as a mechanism to signal that a consumer is "busy" or "blocked." While this mechanism allows for priority-based dispatch, it does not guarantee that messages will wait exclusively for the high-priority consumer if that consumer is at its capacity limit; instead, it allows for "spillover" to lower-priority consumers to maintain system throughput [1][2].
Citations:
- 1: https://www.rabbitmq.com/docs/consumer-priority
- 2: https://www.rabbitmq.com/docs/next/consumer-priority
Require prefetch=1 for the one-message-per-server spread.
The priority dispatch described only spreads across priority levels after higher-priority consumers are blocked. If effective prefetch is greater than one, a priority-3 consumer can hold multiple unacknowledged messages and lower-priority consumers will not receive their share. Set and show prefetch: 1 per binding, and clarify that “busy” means blocked by at least one unacknowledged delivery.
architecture/rabbitmq/rabbit-load-balancing.md#L88-L101architecture/rabbitmq/diagrams/load-balancing-solution.drawio#L16-L29architecture/rabbitmq/diagrams/load-balancing-solution.drawio#L46-L59architecture/rabbitmq/diagrams/load-balancing-solution.drawio#L165-L166
📍 Affects 2 files
architecture/rabbitmq/rabbit-load-balancing.md#L88-L101(this comment)architecture/rabbitmq/diagrams/load-balancing-solution.drawio#L16-L29architecture/rabbitmq/diagrams/load-balancing-solution.drawio#L46-L59architecture/rabbitmq/diagrams/load-balancing-solution.drawio#L165-L166
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@architecture/rabbitmq/rabbit-load-balancing.md` around lines 88 - 101,
Require and show prefetch: 1 for every consumer binding in the priority
load-balancing documentation and all referenced diagram sites:
architecture/rabbitmq/rabbit-load-balancing.md lines 88-101,
architecture/rabbitmq/diagrams/load-balancing-solution.drawio lines 16-29 and
46-59, and architecture/rabbitmq/diagrams/load-balancing-solution.drawio lines
165-166. Clarify that a consumer is “busy” when blocked by at least one
unacknowledged delivery, preserving the one-message-per-server behavior
described by the priority assignments.
| Spring Cloud Stream does **not** support: | ||
| - Customizing individual consumer configuration within a single binding | ||
| - Setting `x-priority` per consumer (only a limited set of parameters can be overridden) | ||
|
|
||
| **Workaround:** Replace 1 binding with `concurrency=4` by **4 separate bindings** each with `concurrency=1`, mapping to 4 distinct functions (`consumeRun0` → `consumeRun3`). | ||
|
|
||
| **Trade-offs of this workaround:** | ||
|
|
||
| | Trade-off | Detail | | ||
| |-----------|--------| | ||
| | Code duplication | Each binding requires a distinct function | | ||
| | Hard concurrency limit | Cannot increase concurrency via config alone | | ||
| | AMQP tight coupling | Requires direct AMQP dependency, removing the broker-agnostic abstraction provided by Spring Cloud Stream | |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
rg -n -C 3 --glob '*.{java,kt}' \
'ListenerContainerCustomizer|setConsumerArguments|x-priority|consumeRun[0-3]' .
rg -n -C 3 --glob '*.{yml,yaml,properties}' \
'consumeRun[0-3]|prefetch' .Repository: gridsuite/documentation
Length of output: 161
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "== repo files matching rabbit/load-balancing =="
fd -a 'rabbit-load-balancing\.md|load-balancing-solution\.drawio' . || true
echo "== markdown excerpt =="
if [ -f "architecture/rabbitmq/rabbit-load-balancing.md" ]; then
nl -ba architecture/rabbitmq/rabbit-load-balancing.md | sed -n '1,150p'
fi
echo "== diagram relevant snippets =="
if [ -f "architecture/rabbitmq/diagrams/load-balancing-solution.drawio" ]; then
sed -n '1,80p' architecture/rabbitmq/diagrams/load-balancing-solution.drawio
fi
echo "== broader SCS config/priority mentions =="
rg -n -C 2 'spring\.cloud|spring\.rabbit|concurrency|prefetch|x-priority|priority|ListenerContainerCustomizer|consumerArguments|consumeRun[0-3]' architecture . --glob '!**/.git/**' || trueRepository: gridsuite/documentation
Length of output: 504
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "== repository files =="
printf '%s\n' /home/jailuser/git/architecture/rabbitmq/rabbit-load-balancing.md
printf '%s\n' /home/jailuser/git/architecture/rabbitmq/diagrams/load-balancing-solution.drawio
echo "== markdown excerpt (1-150) =="
sed -n '1,150p' /home/jailuser/git/architecture/rabbitmq/rabbit-load-balancing.md
echo "== diagram relevant snippets (1-80) =="
sed -n '1,80p' /home/jailuser/git/architecture/rabbitmq/diagrams/load-balancing-solution.drawio
echo "== broader SCS/Rabbit config/priority/code search =="
grep -RIn -C 2 'spring\.cloud|spring\.rabbit|concurrency|prefetch|x-priority|priority|ListenerContainerCustomizer|consumerArguments|consumeRun[0-3]' \
/home/jailuser/git/architecture \
--exclude-dir=.git || trueRepository: gridsuite/documentation
Length of output: 15197
🌐 Web query:
Spring Cloud Stream RabbitMQ binding properties priority x-priority ListenerContainerCustomizer consumerArguments
💡 Result:
In Spring Cloud Stream with the RabbitMQ binder, you can control RabbitMQ consumer priority—which dictates the order in which competing consumers receive messages—using the spring.cloud.stream.rabbit.bindings..consumer.consumer-priority property [1]. Setting this property to an integer value (where larger numbers indicate higher priority) instructs the binder to automatically configure the underlying RabbitMQ listener container with the appropriate x-priority argument [1][2]. Internally, the RabbitMQ binder sets this by calling listenerContainer.setConsumerArguments(consumerArgs), where the argument map includes x-priority [1]. For advanced use cases where you need to manually configure the listener container—such as setting custom consumer arguments not natively exposed by properties—you can use the ListenerContainerCustomizer interface [3]. This is a functional interface that allows you to access and modify the AbstractMessageListenerContainer before it is started [3]: @Bean public ListenerContainerCustomizer<AbstractMessageListenerContainer> customizer { return (container, destinationName, group) -> { Map<String, Object> consumerArgs = new HashMap<>; consumerArgs.put("x-priority", 10); container.setConsumerArguments(consumerArgs); }; } Note that while the RabbitMQ binder provides native support for consumer priority via the consumer-priority property, the ListenerContainerCustomizer approach is a powerful mechanism for applying any low-level container configurations globally or conditionally [3][1]. If you are also interested in message-level priority (the order in which messages are delivered from a queue), you must define the queue as a priority queue by setting the max-priority property (or queue-max-priority in some versions) on your RabbitMQ binding [4][1][5].
Citations:
- 1: Add consumer priority spring-cloud/spring-cloud-stream#3147
- 2: https://www.rabbitmq.com/docs/consumer-priority
- 3: https://docs.spring.io/spring-cloud-stream/docs/Fishtown.BUILD-SNAPSHOT/api/org/springframework/cloud/stream/config/ListenerContainerCustomizer.html
- 4: https://docs.spring.io/spring-cloud-stream/reference/rabbit/rabbit_overview/rabbitmq-consumer-properties.html
- 5: https://docs.spring.io/spring-cloud-stream/docs/current/reference/html/spring-cloud-stream-binder-rabbit.html
🌐 Web query:
RabbitMQ basic.consume x-priority consumer priority consumer arguments documentation
💡 Result:
In RabbitMQ, consumer priority is controlled by setting the x-priority argument during the basic.consume operation [1][2]. Key points regarding x-priority: - Configuration: You pass x-priority as an entry in the arguments table (a map/dictionary) when invoking basic.consume [1][3]. The value must be an integer [1]. - Default Behavior: If a consumer does not specify an x-priority value, it defaults to a priority of 0 [1][4]. - Priority Logic: Larger integer values indicate higher priority [1][5]. Both positive and negative integers are supported [1][2]. - Delivery Mechanism: Normally, RabbitMQ delivers messages to consumers in a round-robin fashion [6][7]. When consumer priorities are used, RabbitMQ ensures that messages are delivered to consumers with the highest priority first [6][7]. Messages are only delivered to lower-priority consumers if the high-priority consumers are blocked or unable to accept more messages (e.g., due to prefetch limits) [6][7]. If multiple active consumers share the same highest priority level, messages are distributed to them in a round-robin manner [6][7]. This feature is useful for scenarios such as prioritizing consumers on more powerful hardware or ensuring data locality by prioritizing consumers connected to the node where the queue master resides [8].
Citations:
- 1: https://www.rabbitmq.com/docs/consumer-priority
- 2: https://www.rabbitmq.com/docs/4.2/consumer-priority
- 3: https://next.rabbitmq.com/consumer-priority.html
- 4: https://www.rabbitmq.com/docs/3.13/consumer-priority
- 5: https://www.rabbitmq.com/docs/4.1/consumer-priority
- 6: https://www.rabbitmq.com/docs/4.1/consumers
- 7: https://www.rabbitmq.com/docs/3.13/consumers
- 8: https://github.com/rabbitmq/rabbitmq-website/blob/main/blog/2013-12-16-using-consumer-priorities-with-rabbitmq/index.md
🌐 Web query:
Spring Cloud Stream RabbitMQ consumer.properties consumerArguments x-priority
💡 Result:
In Spring Cloud Stream with the RabbitMQ binder, you can configure the RabbitMQ x-priority argument for consumers using the consumer-priority property [1]. This property allows you to assign a priority level to consumers, where higher priority consumers receive messages first [1]. To use this feature, configure the property in your application configuration (e.g., application.yml) under the specific binding [1]: spring: cloud: stream: rabbit: bindings: : consumer: consumer-priority: # 0-255 range This property is part of the RabbitMQ binder-specific consumer configuration [1]. When set, the binder automatically handles the underlying RabbitMQ consumer arguments, setting the x-priority value on the listener container [1]. If you need to configure listener container properties that are not explicitly exposed via these binder properties, you can use a ListenerContainerCustomizer bean in your application context [2][3]. This bean allows you to access and modify the AbstractMessageListenerContainer directly [2]. @Bean public ListenerContainerCustomizer containerCustomizer { return (container, dest, group) -> { // Advanced manual configuration Map<String, Object> consumerArgs = new HashMap<>; consumerArgs.put("x-priority", 10); container.setConsumerArguments(consumerArgs); }; } For general configuration, always ensure you are using the correct prefix for RabbitMQ-specific consumer properties: spring.cloud.stream.rabbit.bindings..consumer. [4][5][6].
Citations:
- 1: Add consumer priority spring-cloud/spring-cloud-stream#3147
- 2: https://docs.spring.io/spring-cloud-stream/reference/spring-cloud-stream/binding-properties.html
- 3: https://docs.spring.io/spring-cloud-stream/docs/current-snapshot/reference/html/_rabbitmq_binder.html
- 4: https://docs.spring.io/spring-cloud-stream/reference/rabbit/rabbit_overview/rabbitmq-consumer-properties.html
- 5: https://docs.spring.io/spring-cloud-stream/docs/current-SNAPSHOT/reference/html/spring-cloud-stream-binder-rabbit.html
- 6: https://docs.spring.io/spring-cloud-stream-binder-rabbit/docs/current/reference/html/spring-cloud-stream-binder-rabbit.html
🌐 Web query:
Spring AMQP AbstractMessageListenerContainer setConsumerArguments queue consumer priority basic.consume x-priority
💡 Result:
In Spring AMQP, you can set the consumer priority for asynchronous message listeners by using the x-priority argument via the setConsumerArguments method of the MessageListenerContainer [1][2]. RabbitMQ utilizes this argument in the basic.consume method to determine consumer priority, where higher values indicate higher priority [3]. To set this programmatically on a listener container, you can pass a map containing the key x-priority to the setConsumerArguments method [1][2]: container.setConsumerArguments(Collections.singletonMap("x-priority", Integer.valueOf(10))); Alternatively, when using the XML namespace configuration for a listener container, you can use the priority attribute directly on the listener element, which serves as a convenient shorthand [1][2]: <rabbit:listener-container connection-factory="rabbitConnectionFactory"> <rabbit:listener queues="some.queue" ref="somePojo" method="handle" priority="10" /> </rabbit:listener-container> Note that this configuration applies to asynchronous consumers managed by listener containers (such as SimpleMessageListenerContainer or DirectMessageListenerContainer) [4][1]. It is not used for synchronous consumption via AmqpTemplate or RabbitTemplate [5][6].
Citations:
- 1: https://docs.enterprise.spring.io/spring-amqp/reference/amqp/receiving-messages/async-consumer.html
- 2: https://docs.spring.io/spring-amqp/reference/amqp/receiving-messages/async-consumer.html
- 3: https://www.rabbitmq.com/docs/consumer-priority
- 4: https://docs.enterprise.spring.io/spring-amqp/reference/amqp/containerAttributes.html
- 5: Add ability to set consumer priority with AmqpTemplate spring-projects/spring-amqp#1533
- 6: https://stackoverflow.com/questions/74448938/how-to-set-consumer-priority-with-amqptemplate
🌐 Web query:
Spring Cloud Stream RabbitMQ consumer-priority property support PR 3147 version
💡 Result:
The support for the consumer-priority property in the Spring Cloud Stream RabbitMQ binder was introduced via Pull Request #3147 [1]. This feature allows developers to assign priority levels to consumers, ensuring that higher-priority consumers process messages before lower-priority ones [1]. This pull request was merged into the spring-cloud/spring-cloud-stream repository on October 3, 2025 [1]. It introduced the following properties: - consumer-priority: Defines the consumer priority (0-255) [1]. - queue-max-priority: Defines the queue maximum priority (1-255), which configures the x-max-priority argument on the queue [1]. These properties are typically applied under the binding configuration as follows [1]: spring: cloud: stream: rabbit: bindings: input-in-0: consumer: consumer-priority: 10 queue-max-priority: 10 Please note that PR #3147 in the Spring Cloud Stream repository is distinct from other similarly numbered PRs in other Spring projects (such as PR #3147 in Spring AMQP, which addressed a different issue regarding listener container shutdown) [2]. Because this feature was merged in late 2025, you should ensure you are using a version of the Spring Cloud Stream RabbitMQ binder that includes these changes (likely versions corresponding to release trains following the October 2025 merge).
Citations:
- 1: Add consumer priority spring-cloud/spring-cloud-stream#3147
- 2: Request to delay consumer and listener container shutdown to wait for pending reply messages when using Request/Reply Messaging with a fixed name reply queue. spring-projects/spring-amqp#3031
🌐 Web query:
Spring Cloud Stream RabbitMQ binder consumer-priority consumer queue arguments source
💡 Result:
In Spring Cloud Stream, the RabbitMQ binder supports consumer priority via the consumer-priority configuration property [1]. This setting allows you to influence which consumer instance receives messages from a queue when multiple instances are connected: higher priority consumers receive messages first, while lower priority consumers process messages only when higher priority ones are busy [1]. To configure this, use the following property in your application configuration (YAML or properties format) [1]: spring: cloud: stream: rabbit: bindings: : consumer: consumer-priority: <integer_value> The consumer-priority value should be an integer, typically in the range of 0 to 255 [1]. Implementation Notes: 1. Under the hood, this configuration maps to the RabbitMQ x-priority argument, which is applied to the consumer when it is registered with the RabbitMQ broker [1]. 2. This is distinct from queue-level properties such as queue-max-priority, which configures the queue itself to support prioritized messages (using the x-max-priority argument) [2][1]. 3. The consumer-priority is specific to the consumer instance's behavior, whereas queue-max-priority relates to how messages are ordered within the queue [2][1]. For additional queue customization, you can use the queueBindingArguments property if specific binding-time arguments are required, though consumer-priority is handled directly through the dedicated binder property mentioned above [2][3].
Citations:
- 1: Add consumer priority spring-cloud/spring-cloud-stream#3147
- 2: https://docs.spring.io/spring-cloud-stream/reference/rabbit/rabbit_overview/rabbitmq-consumer-properties.html
- 3: https://docs.spring.io/spring-cloud-stream/docs/current/reference/html/spring-cloud-stream-binder-rabbit.html
Document the actual binding property used for x-priority.
RabbitMQ consumer priority is passed with basic.consume, but Spring Cloud Stream RabbitMQ supports the Rabbit-specific binding property spring.cloud.stream.rabbit.bindings.<binding>.consumer.consumer-priority. The “only a limited set of parameters can be overridden” wording and the diagram area named “Spring Cloud Stream — Config” can mislead readers into thinking YAML cannot set priorities or that a custom AMQP-only change is always required. Add the supported property example, or mark it as version-dependent.
📍 Affects 2 files
architecture/rabbitmq/rabbit-load-balancing.md#L108-L120(this comment)architecture/rabbitmq/diagrams/load-balancing-solution.drawio#L13-L29
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@architecture/rabbitmq/rabbit-load-balancing.md` around lines 108 - 120,
Update architecture/rabbitmq/rabbit-load-balancing.md lines 108-120 to document
the supported RabbitMQ binding property
spring.cloud.stream.rabbit.bindings.<binding>.consumer.consumer-priority,
including a configuration example or an explicit version-dependent caveat;
clarify that YAML can configure x-priority and direct AMQP customization is not
always required. Update
architecture/rabbitmq/diagrams/load-balancing-solution.drawio lines 13-29 to
remove or revise the misleading “Spring Cloud Stream — Config” implication
consistently; no other sites require changes.
| **Relevant issues:** | ||
| - [spring-cloud-stream #3122](https://github.com/spring-cloud/spring-cloud-stream/issues/3122) | ||
| - [spring-amqp #3092](https://github.com/spring-projects/spring-amqp/issues/3092) | ||
| - [spring-cloud-stream #3176](https://github.com/spring-cloud/spring-cloud-stream/issues/3176) (test issues) |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Repository files near rabbit-load-balancing.md:"
fd -a 'rabbit-load-balancing.md' . || true
echo
echo "Context from file around relevant lines:"
if [ -f architecture/rabbitmq/rabbit-load-balancing.md ]; then
nl -ba architecture/rabbitmq/rabbit-load-balancing.md | sed -n '90,140p'
fi
echo
echo "Search for related terms:"
rg -n "test binder|x-priority|issue/3176|one message|same group|RabbitMQ integration|test profile" architecture/rabbitmq/rabbit-load-balancing.md .github README.md 2>/dev/null || trueRepository: gridsuite/documentation
Length of output: 358
🌐 Web query:
spring-cloud-stream issues/3176 Test Binder same group one message every binding
💡 Result:
The issue identified as #3176 in the spring-cloud/spring-cloud-stream repository refers to a limitation in the Test Binder where multiple bindings sharing the same consumer group cause a message to be processed by every binding rather than being distributed among them [1]. In production environments (e.g., using RabbitMQ or Kafka), a consumer group correctly ensures that a message is consumed only once by the group [1]. However, the Test Binder is designed as a simplified, in-JVM message broker primarily for unit testing basic message exchanges and lacks the complex logic required to emulate the varying behaviors of different production messaging systems regarding consumer groups [1][2]. According to maintainer feedback on this issue, the Test Binder was never intended to emulate the full, binder-specific capabilities—such as sophisticated consumer group load balancing—that differ across messaging platforms [1][3]. Consequently, if your application relies on specific consumer group behavior for correctness, it is recommended to perform those tests using a real binder with a corresponding messaging broker (e.g., via Testcontainers) rather than relying on the Test Binder [1][3].
Citations:
- 1: Test binder doesn't support multiple bindings with the same group (message processed twice instead of once per group) spring-cloud/spring-cloud-stream#3176
- 2: https://docs.spring.io/spring-cloud-stream/reference/spring-cloud-stream/spring_integration_test_binder.html
- 3: TestBinder is ignoring routing key spring-cloud/spring-cloud-stream#2041
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Context from architecture/rabbitmq/rabbit-load-balancing.md:"
grep -RIn . 'rabbit-load-balancing.md' >/tmp/filename_check 2>/dev/null || true
cat -n architecture/rabbitmq/rabbit-load-balancing.md | sed -n '90,140p'
echo
echo "Search relevant terms in repository docs/code:"
grep -RIn --exclude-dir=.git --exclude-dir=node_modules \
'3176\|Test Binder\|spring.cloud.stream.test.binder\|consumer group\|x-streams' . || trueRepository: gridsuite/documentation
Length of output: 50380
Describe the Test Binder consumer-group issue.
The Spring Cloud Stream Test Binder links 3176 means bindings in the same consumer group process a published message instead of distributing load once. State that production RabbitMQ delivery only consumes the message once, and require either a RabbitMQ integration test or a test profile that enables only one binding.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@architecture/rabbitmq/rabbit-load-balancing.md` around lines 122 - 125,
Update the “Relevant issues” section in rabbit-load-balancing.md to describe the
Test Binder consumer-group limitation: bindings in the same group may each
process one published message instead of distributing it. State that production
RabbitMQ delivers the message to only one consumer, and require validation
through either a RabbitMQ integration test or a test profile enabling only one
binding.
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@architecture/diagrams/BackendFrontend.drawio`:
- Line 10: Update the diagram labels in the relevant mxCell entries: change
“Librairies” to “Libraries”, “Dyna Mapping Server” to “Dynamic mapping server”,
and “Dynamic Margin Calculator Server” to “Dynamic margin calculation server”,
matching the names documented in MicroServices.md.
In `@architecture/diagrams/gridsuite_architecture.drawio`:
- Line 116: Update the edge labels in the diagram: change “ajust balance on CGM”
to “adjust balance on CGM” and change each “run / get resuts” label to “run /
get results,” including the occurrences associated with the visible edge cells
and the additional referenced locations.
In `@architecture/MicroServices.md`:
- Around line 219-223: Clarify the Gateway description’s “https” responsibility
to align with the SSL termination behavior documented in RequestRouting.md.
Update the security-features wording in the Gateway section to state whether TLS
is terminated by ingress or an external load balancer, or explicitly describe
the Gateway’s actual HTTPS role without implying it performs SSL termination.
In `@architecture/rabbitmq/rabbit-load-balancing.md`:
- Around line 122-125: Update the “Relevant issues” section in
rabbit-load-balancing.md to describe the Test Binder consumer-group limitation:
bindings in the same group may each process one published message instead of
distributing it. State that production RabbitMQ delivers the message to only one
consumer, and require validation through either a RabbitMQ integration test or a
test profile enabling only one binding.
- Around line 88-101: Require and show prefetch: 1 for every consumer binding in
the priority load-balancing documentation and all referenced diagram sites:
architecture/rabbitmq/rabbit-load-balancing.md lines 88-101,
architecture/rabbitmq/diagrams/load-balancing-solution.drawio lines 16-29 and
46-59, and architecture/rabbitmq/diagrams/load-balancing-solution.drawio lines
165-166. Clarify that a consumer is “busy” when blocked by at least one
unacknowledged delivery, preserving the one-message-per-server behavior
described by the priority assignments.
- Around line 108-120: Update architecture/rabbitmq/rabbit-load-balancing.md
lines 108-120 to document the supported RabbitMQ binding property
spring.cloud.stream.rabbit.bindings.<binding>.consumer.consumer-priority,
including a configuration example or an explicit version-dependent caveat;
clarify that YAML can configure x-priority and direct AMQP customization is not
always required. Update
architecture/rabbitmq/diagrams/load-balancing-solution.drawio lines 13-29 to
remove or revise the misleading “Spring Cloud Stream — Config” implication
consistently; no other sites require changes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: f61357b9-c387-4cbd-9168-1f57a5ea9052
⛔ Files ignored due to path filters (7)
architecture/diagrams/BackendFrontend.drawio.svgis excluded by!**/*.svgarchitecture/diagrams/RequestRouting.drawio.svgis excluded by!**/*.svgarchitecture/diagrams/RequestRoutingExample.drawio.svgis excluded by!**/*.svgarchitecture/diagrams/archi_gridsuite.pngis excluded by!**/*.pngarchitecture/diagrams/gridsuite_architecture.svgis excluded by!**/*.svgarchitecture/rabbitmq/diagrams/load-balancing-problem.drawio.svgis excluded by!**/*.svgarchitecture/rabbitmq/diagrams/load-balancing-solution.drawio.svgis excluded by!**/*.svg
📒 Files selected for processing (12)
README.mdarchitecture/Architecture.mdarchitecture/CommonLibraries.mdarchitecture/MicroServices.mdarchitecture/RequestRouting.mdarchitecture/diagrams/BackendFrontend.drawioarchitecture/diagrams/RequestRouting.drawioarchitecture/diagrams/RequestRoutingExample.drawioarchitecture/diagrams/gridsuite_architecture.drawioarchitecture/rabbitmq/diagrams/load-balancing-problem.drawioarchitecture/rabbitmq/diagrams/load-balancing-solution.drawioarchitecture/rabbitmq/rabbit-load-balancing.md
🛑 Comments failed to post (3)
architecture/diagrams/BackendFrontend.drawio (1)
10-10: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Fix a spelling typo and align service names with MicroServices.md.
Line 10 labels a container
"Librairies", the French spelling of "Libraries". Fix this to"Libraries".Line 40 labels a node
"Dyna Mapping Server"and line 199 labels a node"Dynamic Margin Calculator Server".architecture/MicroServices.mddocuments these services as "Dynamic mapping server" and "Dynamic margin calculation server" respectively. Align the diagram labels with the documented service names so cross-referencing the diagram and the catalog is unambiguous.✏️ Proposed label fixes
- <mxCell id="M4A4NaIu_-oz1vJJ0DFB-10" ... value="Librairies" vertex="1"> + <mxCell id="M4A4NaIu_-oz1vJJ0DFB-10" ... value="Libraries" vertex="1">- <mxCell id="rgu2BDKIU-6iCYOQIiJl-47" ... value="Dyna Mapping Server" vertex="1"> + <mxCell id="rgu2BDKIU-6iCYOQIiJl-47" ... value="Dynamic Mapping Server" vertex="1">- <mxCell id="65GGP1cX4v4EcOWwSQA8-4" ... value="Dynamic Margin Calculator Server" vertex="1"> + <mxCell id="65GGP1cX4v4EcOWwSQA8-4" ... value="Dynamic Margin Calculation Server" vertex="1">Also applies to: 40-41, 199-201
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@architecture/diagrams/BackendFrontend.drawio` at line 10, Update the diagram labels in the relevant mxCell entries: change “Librairies” to “Libraries”, “Dyna Mapping Server” to “Dynamic mapping server”, and “Dynamic Margin Calculator Server” to “Dynamic margin calculation server”, matching the names documented in MicroServices.md.architecture/diagrams/gridsuite_architecture.drawio (1)
116-116: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Fix spelling typos in diagram labels.
Line 116 has an edge label
"ajust balance on CGM". Fix the spelling to"adjust balance on CGM".Line 336 and line 869 both have edge labels
"run / get resuts". Fix the spelling to"run / get results", matching the correct spelling already used elsewhere in this file (for example,"run / get results"at line 391 and line 406).✏️ Proposed label fixes
- <mxCell id="dwe6SSOjRqwcFj5i-Lfe-21" value="ajust balance on CGM" ...> + <mxCell id="dwe6SSOjRqwcFj5i-Lfe-21" value="adjust balance on CGM" ...>- <mxCell id="dwe6SSOjRqwcFj5i-Lfe-69" value="run / get resuts" ...> + <mxCell id="dwe6SSOjRqwcFj5i-Lfe-69" value="run / get results" ...>- <mxCell id="dwe6SSOjRqwcFj5i-Lfe-172" value="run / get resuts" ...> + <mxCell id="dwe6SSOjRqwcFj5i-Lfe-172" value="run / get results" ...>Also applies to: 336-336, 869-869
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@architecture/diagrams/gridsuite_architecture.drawio` at line 116, Update the edge labels in the diagram: change “ajust balance on CGM” to “adjust balance on CGM” and change each “run / get resuts” label to “run / get results,” including the occurrences associated with the visible edge cells and the additional referenced locations.architecture/MicroServices.md (1)
219-223: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Clarify the Gateway's "https" responsibility against RequestRouting.md.
This bullet lists "https" as a security feature the gateway implements.
architecture/RequestRouting.mdstates that SSL termination happens at the ingress controller, and notes it can alternatively be handled by an external load balancer. It does not mention the gateway performing SSL termination.Read together, a reader cannot tell whether the gateway terminates or re-terminates TLS, or whether "https" here just means the gateway is only reachable over https. Reword this bullet to match the SSL termination placement described in RequestRouting.md, or clarify the gateway's actual role.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@architecture/MicroServices.md` around lines 219 - 223, Clarify the Gateway description’s “https” responsibility to align with the SSL termination behavior documented in RequestRouting.md. Update the security-features wording in the Gateway section to state whether TLS is terminated by ingress or an external load balancer, or explicitly describe the Gateway’s actual HTTPS role without implying it performs SSL termination.
1 participant
PR Summary