[ https://issues.apache.org/jira/browse/ARTEMIS-4314?focusedWorklogId=865979&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865979 ]
ASF GitHub Bot logged work on ARTEMIS-4314: ------------------------------------------- Author: ASF GitHub Bot Created on: 16/Jun/23 10:11 Start Date: 16/Jun/23 10:11 Worklog Time Spent: 10m Work Description: gtully commented on code in PR #4509: URL: https://github.com/apache/activemq-artemis/pull/4509#discussion_r1232058024 ########## artemis-server/src/main/java/org/apache/activemq/artemis/core/server/Queue.java: ########## @@ -389,6 +389,8 @@ default int retryMessages(Filter filter, Integer expectedHits) throws Exception boolean hasMatchingConsumer(Message message); Review Comment: agree, I was leaving it unchanged but calling it what it is PendingMessageCount is best, sorted. thanks. Issue Time Tracking ------------------- Worklog Id: (was: 865979) Time Spent: 1h 50m (was: 1h 40m) > 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: 1h 50m > 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)