Operating System: All
Platform: All

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.

(In reply to Robert Varga from comment #1)
> 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.

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

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.

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.

(In reply to Jakub Morvay from comment #2)
> (In reply to Robert Varga from comment #1)
> > 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.
>
> 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).
>
> 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.

https://git.opendaylight.org/gerrit/#/c/55921/

carbon:
https://git.opendaylight.org/gerrit/#/c/56061/