[
https://issues.apache.org/jira/browse/AMQ-9689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17943568#comment-17943568
]
ASF subversion and git services commented on AMQ-9689:
------------------------------------------------------
Commit 182c598df544661e0d2e947dafaf1020ca331d6d in activemq's branch
refs/heads/activemq-6.1.x from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=182c598df5 ]
AMQ-9689 - Network of Broker durable sync TTL fixes and improvements (#1419)
This commit makes several improvements and fixes for syncing durable
subscriptions when a network bridge connects.
1) A bug was fixed 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.
2) During reactivation when dynamicOnly is false and durable sync is set
to true, we 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. Thisonly 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.
3) For TTL 1, we can 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.
4) Some other minor improvements were made like filtering everything if
TTL is 0 and also consolidating logic.
(cherry picked from commit 953737ca082e1ff67cf0b408e7ec72cd89be75ac)
> 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 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
