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/CONTROLLER-1063 controller <p>The Clustered Data Store ensures that all reads are consistent by routing reads to the Shard Leader. This obviously has an adverse impact on application performance. We need to provide a mechanism in the API or via configuration so that application developers and/or administrators can choose to allow reads from a follower. </p> <p>It goes without saying that applications that choose to use this mechanism will have to deal with the situation where a ReadTransaction following a WriteTransaction may not see the data written by the WriteTransaction.</p> <p>Also the support to read from a follower cannot be implemented when transactions occur on a TransactionChain.</p> <p>Operating System: All<br/> Platform: All</p> CONTROLLER-1063

Clustering : Add support to allow reads from followers

Improvement Confirmed Unresolved Unassigned Moiz Raja Thu, 11 Dec 2014 16:29:23 +0000 Tue, 25 Jul 2023 08:23:50 +0000 clustering 0 5 <p>No clear use case so moving it out of Be</p> <p>There is a way to currently do this - it's a bit convoluted but it would work.</p> <p>The way is to register a DataChangeListener. The Listener should be of type ClusteredDataChangeListener. When the Listener is registered it sends an initial notification with all the pertinent data from the local replica. After the initial notification is received the data can be read from the CreatedData map and the listener can be unregistered. This effectively gives us a mechanism to read data from the follower.</p> <p>An alternative is to provide an interface extension in the DOMDataTreeProducer (or consumer) contract, which will backchannel the request. Frontend implementation can then satisfy the read either from its replica (if present), or by establishing an internal consumer, or via explicit read.</p> <p>please see below mail threads for more info on proposed implementation:</p> <p><a href="https://lists.opendaylight.org/pipermail/mdsal-dev/2016-December/000881.html" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/mdsal-dev/2016-December/000881.html</a><br/> <a href="https://lists.opendaylight.org/pipermail/mdsal-dev/2016-December/000859.html" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/mdsal-dev/2016-December/000859.html</a><br/> <a href="https://lists.opendaylight.org/pipermail/mdsal-dev/2016-December/000853.html" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/mdsal-dev/2016-December/000853.html</a></p> <p>I think there is a semantic mismatch between this issue and the request discussed in the referenced thread.</p> <p>The assumption in this issue is that the follower is located on the current node and if not, the read will go to the master.</p> <p>The discussion in the mailing thread is about a cache, which is initially populated from wherever and is being maintained going forward.</p> <p>The difference is that this issue makes an assumption on follower locality, while the cache does not. This is an important distinction in clusters where there is no shard presence (leader/follower) on some nodes.</p> <p>&gt; mismatch between this issue and the request discussed in the referenced thread</p> <p>==&gt; <a href="https://jira.opendaylight.org/browse/MDSAL-217" title="Cache support API to improve clustered data reads performance" class="issue-link" data-issue-key="MDSAL-217"><del>MDSAL-217</del></a> opened (by Ravit)</p> Blocks CONTROLLER-918 Development External issue ID 2504 External issue URL Issue Type ODL SR Target Milestone Rank 0|i02o9b: