[
https://issues.apache.org/jira/browse/ARTEMIS-5304?focusedWorklogId=956943&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-956943
]
ASF GitHub Bot logged work on ARTEMIS-5304:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 13/Feb/25 17:45
Start Date: 13/Feb/25 17:45
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #5493:
URL: https://github.com/apache/activemq-artemis/pull/5493#discussion_r1954954935
##########
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/connect/federation/AMQPFederationConfiguration.java:
##########
@@ -76,12 +77,20 @@ public final class AMQPFederationConfiguration {
public static final boolean DEFAULT_IGNNORE_QUEUE_CONSUMER_PRIORITIES =
false;
/**
- * Default timeout (milliseconds) applied to federation receivers that are
being closed due to removal
+ * Default timeout (milliseconds) applied to federation receivers that are
being stopped due to removal
* of local demand and need to drain link credit and process any in-flight
deliveries before closure.
* If the timeout elapses before the link has quiesced the link is forcibly
closed.
*/
public static final int DEFAULT_RECEIVER_QUIESCE_TIMEOUT = 60_000;
+ /**
+ * Default timeout (milliseconds) applied to federation receivers that have
been stopped due to lack of
+ * local demand. The close delay prevent a link from detaching in cases
where demand drops and returns
+ * in quick succession allowing for faster recovery. The idle timeout kicks
in once the link has completed
+ * its drain of outstanding credit.
+ */
+ public static final int DEFAULT_RECEIVER_IDLE_TIMEOUT = 60_000;
Review Comment:
I'd maybe be inclined to lower this given it acts as a default for both
queue and address types. Its fine for queue federation, but given the scope for
oddities to arise in some Address federation cases due to the federation
consumer (and its related queue) sticking around between source demand, it
seems like lower default would be appropriate there. Although I realise it can
of course be configured to 0 both overall and/or on a per-policy basis for
anyone that needs to.
Issue Time Tracking
-------------------
Worklog Id: (was: 956943)
Time Spent: 40m (was: 0.5h)
> Allow AMQP Federation consumer to idle for a period of time when demand is
> removed
> ----------------------------------------------------------------------------------
>
> Key: ARTEMIS-5304
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5304
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: AMQP
> Affects Versions: 2.39.0
> Reporter: Timothy A. Bish
> Assignee: Timothy A. Bish
> Priority: Minor
> Labels: pull-request-available
> Fix For: 2.40.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When demand is removed from a tracked address or queue the AMQP federation
> instance will drain the receiver link and then close it which can lead of
> attach / detach of receiver links in cases where the receiver that generated
> the demand comes back quickly. This can happen based on the framework in use
> by the application or from spotty networks. We should idle the consumer for
> some period of time before closing after we drain the link credit to allow
> for quick recovery by simply granting a new batch of credit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
