[ https://issues.apache.org/jira/browse/ARTEMIS-4314?focusedWorklogId=866121&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-866121 ]
ASF GitHub Bot logged work on ARTEMIS-4314: ------------------------------------------- Author: ASF GitHub Bot Created on: 17/Jun/23 00:20 Start Date: 17/Jun/23 00:20 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4511: URL: https://github.com/apache/activemq-artemis/pull/4511 Issue Time Tracking ------------------- Worklog Id: (was: 866121) Time Spent: 2h 40m (was: 2.5h) > Federation, support consumerWindowSize zero and federate in batches only when > the local queue is has excess capacity > -------------------------------------------------------------------------------------------------------------------- > > Key: ARTEMIS-4314 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4314 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation > Affects Versions: 2.28.0 > Reporter: Gary Tully > Assignee: Gary Tully > Priority: Major > Fix For: 2.29.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Dual queue federation, where clusters federate in both direction can suffer > from message flip flopping once the priority adjustment kicks in. > If there is a large backlog, the lower priority federation consumer is in > play once all of the local consumer credit is exhausted and the backlog can > drain to the other cluster. > If demand is low there, the process can repeat. limiting the rate of the > federation consumer can help but it is not ideal b/c when there is no local > demand, we want to have a high rate of migration. > > A possible solution is to have the federation consumer manage its own credit > and only flow messages when the local queue has capacity. Then flow a batch > of messages, and await again that the local queue has capacity. In this way, > there is no thundering herd effect, but there is also fast migration of > messages once there is demand. > the consumerWindowSize=0 is already in play for consumer.receive calls and > there is already a defaultConsumerWindowSize for an address. These can be > combined to realise batchFederationOnCapacity semantics. -- This message was sent by Atlassian Jira (v8.20.10#820010)