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-1624 controller <p>The scenario is as follows.</p> <p>We have a DistributedShardChangePublisher that listens on shard's data tree change events and this shard has also some subshards. Then it seems that we are assuming that the DistributedShardChangePublisher will be notified with shard's data tree change event before any data tree change event from subshards.</p> <p>Clearly we cannot assure that.</p> <p>Operating System: All<br/> Platform: All</p> CONTROLLER-1624

DistributedShardChangePublisher seems to be vulnerable to shard's data tree change events ordering

Bug Resolved Done Jakub Morvay Jakub Morvay Thu, 30 Mar 2017 17:14:50 +0000 Tue, 25 Jul 2023 08:24:28 +0000 Thu, 27 Apr 2017 11:09:30 +0000 clustering 0 2 <p>Right, so we need to stage the logic such that it has an initial phase when it records changes from subshards and only switches to assembling the data once it has observed the change from its own data tree.</p> <p>(In reply to Robert Varga from comment #1)<br/> &gt; Right, so we need to stage the logic such that it has an initial phase when<br/> &gt; it records changes from subshards and only switches to assembling the data<br/> &gt; once it has observed the change from its own data tree.</p> <p>Yeah, I was thinking about something similar. But we cannot know if there are any changes in subshards at all, so we cannot really wait for them (at least with current shard's data tree change listeners implementation).</p> <p>Another approach could be something like "caching" changes from subshards. If the change from subshard cannot be processed, because the change from shard's own data tree is still missing, we can just postpone processing of this change from subshard. Once we get the change event also for shard's own data tree, we can try to assemble the data also with cached changes from subshards. But this has to be thought trough in more detail.</p> <p>This has come up in general with DTCLs, ie the fact that it doesn't notify initially if there's no data. We could pretty easily change the backend to pass an empty change list but it technically breaks the DTCL API contract as it states that the passed list won't be empty. Perhaps we should just address this in Nitrogen. It would really simplify the blueprint clustered-app-config as well.</p> <p>(In reply to Jakub Morvay from comment #2)<br/> &gt; (In reply to Robert Varga from comment #1)<br/> &gt; &gt; Right, so we need to stage the logic such that it has an initial phase when<br/> &gt; &gt; it records changes from subshards and only switches to assembling the data<br/> &gt; &gt; once it has observed the change from its own data tree.<br/> &gt; <br/> &gt; Yeah, I was thinking about something similar. But we cannot know if there<br/> &gt; are any changes in subshards at all, so we cannot really wait for them (at<br/> &gt; least with current shard's data tree change listeners implementation).<br/> &gt; <br/> &gt; Another approach could be something like "caching" changes from subshards.<br/> &gt; If the change from subshard cannot be processed, because the change from<br/> &gt; shard's own data tree is still missing, we can just postpone processing of<br/> &gt; this change from subshard. Once we get the change event also for shard's own<br/> &gt; data tree, we can try to assemble the data also with cached changes from<br/> &gt; subshards. But this has to be thought trough in more detail.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/55921/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/55921/</a></p> <p>carbon:<br/> <a href="https://git.opendaylight.org/gerrit/#/c/56061/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/56061/</a></p> Development External issue ID 8116 External issue URL Issue Type ODL SR Target Milestone Rank 0|i02rpz: