[jira] [Work started] (AMQ-9689) Network of Broker durable sync TTL fixes and improvements

["Christopher L. Shannon (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AMQ-9689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on AMQ-9689 started by Christopher L. Shannon.
---------------------------------------------------
> 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: 50m
>  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 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.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@activemq.apache.org
For additional commands, e-mail: issues-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact