[MDSAL-342] DataObjectModification not able find child via getModifiedChildContainer Created: 22/May/18  Updated: 04/Aug/18  Resolved: 04/Aug/18

Status: Resolved
Project: mdsal
Component/s: None
Affects Version/s: None
Fix Version/s: Fluorine

Type: Improvement Priority: Medium
Reporter: Claudio David Gasparini Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by MDSAL-45 InstanceIdentifier does not properly ... Resolved

 Description   

 

Given the models [0], when listening for changes and trying to get child from 

DataObjectModification using MvpnRoutes.class. 

Issue seems to be coming from LazyDataObjectModification, when obtaining 

BindingCodecTreeNode which generates PathArgumentes using Ipv6 Module,

when the required one is the Ipv4 Module.

It can be reproduced using patch [1]

[0] https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=tree;f=bgp/mvpn/src/main/yang;h=cc6cd734b3b1cddd2b957365e32b6c1796dbcb21;hb=refs/heads/master

[1] https://git.opendaylight.org/gerrit/#/c/72160/

 Comments   
Comment by Robert Varga [ 22/May/18 ]

Can you minimize the test case to a write+listen change? Debugging a full asynchronous serialize+parse+process case is a bit of a tall order for my memory of BGP

Comment by Claudio David Gasparini [ 23/May/18 ]

I was trying to reproduce it on that way, but I hit MDSAL-343.

Between, running in debug mode testUseCase1

  • set debug point on [0], there is log comment point where we expect to get child information.
  • if we remove [1], then we will get the information without any issue. I compared the information under DataObjectModification<Tables> table for both scenarios and it is the same. BindingCodecTreeNode(LazyDataObjectModification) will generate different bindingPathArgument for Child on each scenario, but only one using the correct module(ipv4) .

 

[0] https://git.opendaylight.org/gerrit/#/c/72160/2/bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/EffectiveRibInWriter.java

[1] https://git.opendaylight.org/gerrit/#/c/72160/2/bgp/rib-impl/src/test/java/org/opendaylight/protocol/bgp/rib/impl/AbstractAddPathTest.java

Comment by Robert Varga [ 23/May/18 ]

This issue no longer blocks, as it has been worked around by modifying the model In order to solve it, we need some help from MDSAL-45. We then need to define a similar API for dealing with ambiguous case members.

Generated at Wed Feb 07 20:09:34 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.