[
https://issues.apache.org/jira/browse/AMQ-9689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated AMQ-9689:
----------------------------------------
Description:
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 subscription reactivation when dynamicOnly is
false that would cause the clientId to not be included in the consumer advisory
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 and sync, when {{dynamicOnly}} is false and durable sync
is set to true, 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 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.
was:
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 following updates are being made:
# A fix for a bug during durable subscription reactivation when dynamicOnly is
false that would cause the clientId to not be included in the consumer advisory
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 and sync, when {{dynamicOnly}} is false and durable sync
is set to true, 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 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.
> 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
>
>
> 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 subscription reactivation when dynamicOnly
> is false that would cause the clientId to not be included in the consumer
> advisory 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 and sync, when {{dynamicOnly}} is false and durable
> sync is set to true, 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 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
