[
https://issues.apache.org/jira/browse/AMQ-9689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated AMQ-9689:
----------------------------------------
Fix Version/s: 5.19.1
6.1.7
> 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, 5.19.1, 6.1.7
>
> 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 minor bug as well where the clientId
> for the network durables during sync was not looked at so the sending side
> would send extra durables over. The receiving side should have still filtered
> but this may have not worked all the time, it's hard to tell. Either way the
> new version filters properly both on the send/receiving side and reduces
> traffic as well.
> *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 where the cliendId was not used to
> filter durables on send so the subscription list could contain extra durables
> that it shouldn't. In theory on the receiving side it should have checked and
> filtered but I think there may have been cases that could cause a loop,
> either way this reduces the extra traffic and is an improvement on the sync.
> # 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, a bug has been fixed as well on the sync for proxy durables. 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. Previously extra demand could be created
> on broker restart due to the missing TTL info so this is a bug fixed by this.
> # 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
