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