[
https://issues.apache.org/jira/browse/ARTEMIS-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736168#comment-17736168
]
Gary Tully commented on ARTEMIS-4314:
-------------------------------------
[~clebertsuconic] I reverted your tweak, there is contention on the
pendingcount check which shows up in the test failing intermittently. Put it in
a loop in idea and it will fail quite quickly. without it, all is good.
see:
at
org.apache.activemq.artemis.tests.integration.federation.FederatedQueuePullConsumerTest.testFederatedQueuePullFromUpstream(FederatedQueuePullConsumerTest.java:189)
> 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.29.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Priority: Major
> Fix For: 2.30.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)
