rvais commented on code in PR #4509:
URL: https://github.com/apache/activemq-artemis/pull/4509#discussion_r1325859328
##########
docs/user-manual/en/federation-queue.md:
##########
@@ -49,6 +49,10 @@ e.g. as many messages as possible are consumed from the same
broker as they were
Here for such a migration with blue/green or canary moving a number of
consumers on the same queue, you may want to set the `priority-adjustment` to
0, or even a positive value, so message would actively flow to the federated
queue.
+* Dual Federation - potential for messages to flip-flop between clusters.
+ If the backlog on your queues exceeds the available local credit across
consumers, any lower priority federation consumer becomes a candidate for
dispatch and messages will be federated. Eventually all messages may migrate
and the scenario can repeat on the other cluster. Applying a rate limit to the
connector url can help mitigate but this could have an adverse effect on
migration when there are no local consumers.
+ To better support this use case, it is possible to configure the
consumerWindowSize to zero on the referenced connector URI:
```tcp://<host>:<port>?consumerWindowSize=0```. This will cause the federation
consumer to pull messages in batches only when the local queue has excess
capacity. This means that federation won't ever drain more messaces than it can
handle, such that messages would flip-flop. The batch size is derived from the
relevant address settings defaultConsumerWindowSize.
Review Comment:
Typo in following text: This means that federation won't ever drain more
_**messaces**_ than it can hand ...
I suppose the word "messages" should be there.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
