[
https://issues.apache.org/jira/browse/AMQ-9689?focusedWorklogId=965723&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-965723
]
ASF GitHub Bot logged work on AMQ-9689:
---------------------------------------
Author: ASF GitHub Bot
Created on: 11/Apr/25 12:14
Start Date: 11/Apr/25 12:14
Worklog Time Spent: 10m
Work Description: cshannon merged PR #1419:
URL: https://github.com/apache/activemq/pull/1419
Issue Time Tracking
-------------------
Worklog Id: (was: 965723)
Time Spent: 1h 10m (was: 1h)
> Network of Broker durable sync TTL fixes and improvements
> ---------------------------------------------------------
>
> Key: AMQ-9689
> URL: https://issues.apache.org/jira/browse/AMQ-9689
> Project: ActiveMQ Classic
> Issue Type: Bug
> Affects Versions: 5.19.0, 6.1.6
> Reporter: Christopher L. Shannon
> Assignee: Christopher L. Shannon
> Priority: Major
> Fix For: 6.2.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Some recent testing has shown a few issues related to the syncing and
> reactivation of durable subscriptions over a network of brokers related to
> TTL.
> The root cause of the problem is that when the durable subscriptions are
> first created the original consumer info is attached to the advisories and
> TTL information is available so that the consumerTTL can be checked and
> subscriptions will not propagate where they shouldn't. The problem is when
> brokers are restarted, the durable sync that is done (and also re-activation
> of durables when dynamicOnly is false) may process the durables when they are
> offline still and those durables will be missing the consumer info and not
> contain the brokerPath anymore for what created the durable.
> This means that in some scenarios extra demand and durables get created when
> they shouldn't based on TTL. There was a bug as well where the clientId for
> the network durables during sync could be missing and that could prevent
> proper detection of loops because the remote broker would not be able to
> detect what bridge and broker created that subscription.
> *Note:* We can some of the bugs and issues, but for TTL > 1, the only true
> way to prevent demand from propagating on broker restarts with offline
> durables in all cases is to set {{dynamicOnly}} to *true* and allow fully
> consumer driven demand. Otherwise on restart and sync, if the durables are
> still offline, TTL info is missing. We can still handle the ttl -1 and TTL 1
> case entirely.
> The following updates and fixes are being made to address the issues:
> # A fix for a bug during durable sync that would cause the clientId to not
> always be included for durables in the subscription list which could cause a
> loop to be created as the other broker would not be able to tell where the
> network subscription came from.
> # During reactivation, when {{dynamicOnly}} is false, we should make sure to
> include the TTL information (full broker path) from the online consumer
> attached to durables so that TTL info is properly propagated so we don't
> incorrectly create demand. This only works if consumers are online, so for
> TTL > 1 it is still recommended to set dynamicOnly to true and allow only
> online consumers drive demand.
> # For TTL 1, we can improve the filtering and now handle sync correctly on
> restarts even if durables are offline and missing consumer TTL info because
> we know that we should ignore proxy durables (bridge durables for other
> bridges) entirely because they will be > 1 hop away.
> # Some other minor improvements were made like filtering everything if TTL is
> 0 and also consolidating logic.
--
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
