[
https://issues.apache.org/jira/browse/ARTEMIS-4314?focusedWorklogId=865881&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865881
]
ASF GitHub Bot logged work on ARTEMIS-4314:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 15/Jun/23 21:03
Start Date: 15/Jun/23 21:03
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on PR #4509:
URL:
https://github.com/apache/activemq-artemis/pull/4509#issuecomment-1593720505
@gtully for some reason I am not being able to make a PR to your repo.
Github is not recognizing your user on the filters and giving me a hard time.
So, I created a branch you can pull the commit:
https://github.com/clebertsuconic/activemq-artemis/tree/_4314
Basically you will endup in this calling flowControl method. which needs to
be protected and using the same thread used to deliver. it's not just that
state.. any call to flowControl has to be done through the same thread used to
deliver... otherwise you will have races on the number of credits.
Issue Time Tracking
-------------------
Worklog Id: (was: 865881)
Time Spent: 50m (was: 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: 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)
