https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/MDSAL-819 mdsal <p>The distinction through a dedicated sub-class is quite weird and is a source of bugs (like <a href="https://jira.opendaylight.org/browse/AAA-258" title="aaa-encrypt-service fails to start on follower nodes" class="issue-link" data-issue-key="AAA-258"><del>AAA-258</del></a>) and quite ugly hacks (in implementations).<br/> Remove ClusteredDataTreeChangeListener interface and instead of that let the users specify the policy during registration.</p> MDSAL-819

Deprecate Clustered(DOM)DataTreeChangeListener

Improvement Medium Resolved Done Ruslan Kashapov Robert Varga pt Mon, 27 Mar 2023 07:21:46 +0000 Sat, 20 Jan 2024 16:36:37 +0000 Fri, 19 Jan 2024 11:50:14 +0000 13.0.0 Binding API DOM API 0 2 <p>The only place where ClusteredDataTreeChangeListener is actually differentiated from "non-clustered" DataTreeChangeListener is <b>sal-distributed-datastore</b> component of Controller. <a href="https://github.com/opendaylight/controller/blob/4acf2cb993eccd2546a8c374d7fa2716ff2d7a4d/opendaylight/md-sal/sal-distributed-datastore/src/main/java/org/opendaylight/controller/cluster/datastore/DataTreeChangeListenerProxy.java#L110" class="external-link" target="_blank" rel="nofollow noopener">DataTreeChangeListenerProxy</a> converts the listener interface difference into a boolean value <ins><em>registerOnAllInstances</em></ins> which then used in subsequent logic (akka message RegisterDataTreeChangeListener processed by <a href="https://github.com/opendaylight/controller/blob/4acf2cb993eccd2546a8c374d7fa2716ff2d7a4d/opendaylight/md-sal/sal-distributed-datastore/src/main/java/org/opendaylight/controller/cluster/datastore/DataTreeChangeListenerSupport.java#L84" class="external-link" target="_blank" rel="nofollow noopener">DataTreeChangeListenerSupport#onMessage</a>).</p> <p>Specifying the policy on listener registration actually means moving the mentioned boolean property (defined using marking interface) from out of listener. So the new boolean property and listener instance now need to be delivered to same consumer independently of each other. </p> <p>Changing registration listener API is expected to be significant. Following basic interfaces and <b>all the ancestors</b> need to be changed in order to add new parameter to <ins><em>registerDataTreeChangeListener()</em></ins> API method :</p> <ul> <li>DataTreeChangeService (mdsal-binding-api, extended by DataBroker)</li> <li>DOMDataTreeChangeService (mdsal-dom-api)</li> <li>DOMStoreTreeChangePublisher (mdsal-dom-spi)</li> </ul> <p><b>All the</b> affected implementations will require an update no mater the new parameter is taken into account (sal-distributed-datastore) or just ignored (all the other cases).</p> <p>From other hand the condition of either listener should be enabled for notifications on each node or only on a leader is mainly defined by listener purpose (implementation):</p> <ul> <li>if it serves the states synchronization (like cache or configuration update) for local services then it's expected to be enabled on each node</li> <li>if it generates new data/events and multiple active instances (doing same) could cause conflicts and/or resource waste then the listener expected to be active on single node</li> </ul> <p>It means the single/all nodes activation mode property actually defined by (belongs to) listener, no reason to extract it out. It's easier and more safe (reliable) just to convert extra listener interface into actual property of a listener with clear naming/description of the option purpose/usage – see <a href="https://git.opendaylight.org/gerrit/c/mdsal/+/107868" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/c/mdsal/+/107868</a></p> <p>While this approach serves removal of extra listener interface and makes the clustered case  usage more clear, this is mainly a cosmetic change, no performance impact is expected. Some may find this update unnecessary bc using of marking interface already works as expected. The further changes need clarification either to continue the update or leave as is.</p> <p>Thank you for exhaustive analysis. The task is still relevant as it was originally defined.</p> Relates AAA-258 Development Rank 0|i044mv: