[ 
https://issues.apache.org/jira/browse/ARTEMIS-4314?focusedWorklogId=865870&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-865870
 ]

ASF GitHub Bot logged work on ARTEMIS-4314:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 15/Jun/23 20:07
            Start Date: 15/Jun/23 20:07
    Worklog Time Spent: 10m 
      Work Description: clebertsuconic commented on code in PR #4509:
URL: https://github.com/apache/activemq-artemis/pull/4509#discussion_r1231485362


##########
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:
   If you're using this outside of ring, I would rename this to something 
else...
   
   
   getRawMessageCount (terrible name I know.. but anything removing the "ring" 
term)





Issue Time Tracking
-------------------

    Worklog Id:     (was: 865870)
    Time Spent: 0.5h  (was: 20m)

> 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: 0.5h
>  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)

Reply via email to