[
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 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, 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.
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 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.
> 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 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, 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
