Hi Robert My bad... I forgot to mention that the code details.
Yes, this is a single node all-in-one scenario. Currently the code is in gerrit patch (https://git.opendaylight.org/gerrit/#/c/50259/) and the yang models that this patch depend on are in patch (https://git.opendaylight.org/gerrit/#/c/53632/) Just to connect to my previous e-mail: Step1: in NeutronPortChangeListener.java (line 227) Step2: in ElanInterfaceConfigVppListener.java (line 57) Step3: in ElanInterfaceVppRenderer.java (line 132 & 271) Hope this is helpful. Regarding passing the subtree as received in the DCN to the ELAN handler, I can do that with little bit of change in my code logic, but not sure if there are any unknown side effects... Thanks Srikanth -----Original Message----- From: Robert Varga [mailto:n...@hq.sk] Sent: Saturday, April 15, 2017 12:40 AM To: Srikanth Vavilapalli <srikanth.vavilapa...@ericsson.com>; netvirt-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; controller-dev@lists.opendaylight.org Subject: Re: [mdsal-dev] Order of MD-SAL Data Change Notification event and actual data written to the store On 14/04/17 23:34, Srikanth Vavilapalli wrote: > Hi > > > > I am noticing intermittently a race condition behavior where DCN > listener is getting notified about a change in the yang data even > before the data is fully written to and available in the data store. > > > > Let me explain the scenario: > > > > 1. This scenario involves three components: neutron-vpn, > netvirt-Interface-dcn-listener, netvirt-elan-manager > > 2. When a Neutron port is updated: > > a. _Step1_: The neutron-vpn component *updates genius Interface > yang model* using WriteTransaction.put() > > b. _Step2_: The netvirt-Interface-dcn-listener, which listens to > DCN of genius Interface yang models, *gets notified of the change in > the Interface model*. On receiving this notification, > netvirt-interface-dcn-listener invokes a method in netvirt-elan-manager. It is this a bit hard to reason about this without having actual code pointers. What are the classes involved? I cannot find ElanInterfaceConfigVppListener anywhere in the code base. Also, is a single-node scenario? > > c. _Step3_: On invocation of the handler method, the > netvirt-elan-manager *will read the Interface model data from data > store* using ReadOnlyTransaction.read() to proceed with its logic Since the trigger is coming from a change notification, wouldn't it be better to just pass the subtree to elan manager? Regards, Robert > > 3. The observation is, intermittently, in step3, when > netvirt-elan-manager reads from the config data store, it is receiving > the data prior to the Step1 (i.e. old data) instead of updated data. > > 4. I collected some logs at step2 and step3 to suspect this race > condition behavior: > > a. Step2: > > i. > 2017-04-12 23:37:31,697 | TRACE | eChangeHandler-0 | > ElanInterfaceConfigVppListener | 407 - > org.opendaylight.netvirt.elanmanager-impl - 0.4.0.SNAPSHOT | > *Operation Interface update event* - *Old*: > Interface{getName=fa4b736a-a35a-4dc9-8e36-2f6f6d057a2d, getType=class > org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.iana._if.type > .rev140508.L2vlan, isEnabled=true, augmentations={interface > org.opendaylight.yang.gen.v1.urn.opendaylight.genius.interfacemanager. > rev160406.IfL2vlan=IfL2vlan{getL2vlanMode=Trunk}, > interface > org.opendaylight.yang.gen.v1.urn.opendaylight.netvirt.aclservice.rev16 > 0608.InterfaceAcl=InterfaceAcl{getAllowedAddressPairs=[AllowedAddressP > airs{getIpAddress=IpPrefixOrAddress > [_ipAddress=IpAddress [_ipv6Address=Ipv6Address > [_value=fe80:0:0:0:f816:3eff:fed9:9ab4]]], getMacAddress=MacAddress > [_value=fa:16:3e:d9:9a:b4], augmentations={}}, > AllowedAddressPairs{getIpAddress=IpPrefixOrAddress > [_ipAddress=IpAddress [_ipv4Address=Ipv4Address [_value=1.0.0.9]]], > getMacAddress=MacAddress [_value=fa:16:3e:d9:9a:b4], > augmentations={}}], getSecurityGroups=[Uuid > [_value=7a33bbaa-a251-4c77-bc5b-de7c2e621e72]], > isPortSecurityEnabled=true}, interface > org.opendaylight.yang.gen.v1.urn.opendaylight.genius.interfacemanager. > rev160406.ParentRefs=ParentRefs{getDeviceOwner=class > org.opendaylight.yang.gen.v1.urn.opendaylight.genius.interfacemanager. > rev160406.InterfaceDeviceTypeCompute, > getNodeIdentifier=[NodeIdentifier{getNodeId=overcloud-controller-0.opn > fvlf.org, getTopologyId=topology-netconf, augmentations={}}], > getVifType=class > org.opendaylight.yang.gen.v1.urn.opendaylight.genius.interfacemanager. > rev160406.*InterfaceVifTypeUnbound*, > getVnicType=class > org.opendaylight.yang.gen.v1.urn.opendaylight.genius.interfacemanager. > rev160406.InterfaceVnicTypeNormal}}}, > *New*: Interface{getName=fa4b736a-a35a-4dc9-8e36-2f6f6d057a2d, > getType=class > org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.iana._if.type > .rev140508.L2vlan, isEnabled=true, augmentations={interface > org.opendaylight.yang.gen.v1.urn.opendaylight.genius.interfacemanager. > rev160406.IfL2vlan=IfL2vlan{getL2vlanMode=Trunk}, > interface > org.opendaylight.yang.gen.v1.urn.opendaylight.netvirt.aclservice.rev16 > 0608.InterfaceAcl=InterfaceAcl{getAllowedAddressPairs=[AllowedAddressP > airs{getIpAddress=IpPrefixOrAddress > [_ipAddress=IpAddress [_ipv6Address=Ipv6Address > [_value=fe80:0:0:0:f816:3eff:fed9:9ab4]]], getMacAddress=MacAddress > [_value=fa:16:3e:d9:9a:b4], augmentations={}}, > AllowedAddressPairs{getIpAddress=IpPrefixOrAddress > [_ipAddress=IpAddress [_ipv4Address=Ipv4Address [_value=1.0.0.9]]], > getMacAddress=MacAddress [_value=fa:16:3e:d9:9a:b4], > augmentations={}}], getSecurityGroups=[Uuid > [_value=7a33bbaa-a251-4c77-bc5b-de7c2e621e72]], > isPortSecurityEnabled=true}, interface > org.opendaylight.yang.gen.v1.urn.opendaylight.genius.interfacemanager. > rev160406.ParentRefs=ParentRefs{getDeviceOwner=class > org.opendaylight.yang.gen.v1.urn.opendaylight.genius.interfacemanager. > rev160406.InterfaceDeviceTypeCompute, > getNodeIdentifier=[NodeIdentifier{getNodeId=overcloud-controller-0.opn > fvlf.org, getTopologyId=topology-netconf, augmentations={}}], > getVifDetails=[VifDetails{getVifDetailsKey=port_prefix, > getVifDetailsValue=socket_, augmentations={}}, > VifDetails{getVifDetailsKey=vhostuser_mode, getVifDetailsValue=server, > augmentations={}}, VifDetails{getVifDetailsKey=support_vhost_user, > getVifDetailsValue=True, augmentations={}}, > VifDetails{getVifDetailsKey=has_datapath_type_netdev, > getVifDetailsValue=False, augmentations={}}, > VifDetails{getVifDetailsKey=vhostuser_socket_dir, > getVifDetailsValue=/tmp/, augmentations={}}, > VifDetails{getVifDetailsKey=vhostuser_socket, > getVifDetailsValue=/tmp/socket_fa4b736a-a35a-, augmentations={}}], > getVifType=class > org.opendaylight.yang.gen.v1.urn.opendaylight.genius.interfacemanager. > rev160406.*InterfaceVifTypeVhostuser*, > getVnicType=class > org.opendaylight.yang.gen.v1.urn.opendaylight.genius.interfacemanager. > rev160406.InterfaceVnicTypeNormal}}} > > b. Step3: > > i. > 2017-04-12 23:37:31,697 | TRACE | eChangeHandler-0 | > ElanInterfaceVppRenderer | 407 - > org.opendaylight.netvirt.elanmanager-impl - 0.4.0.SNAPSHOT | > isVPPInterface: vifType class > org.opendaylight.yang.gen.v1.urn.opendaylight.genius.interfacemanager. > rev160406.*InterfaceVifTypeUnbound* > is not vhostuser > > 5. In step3, I am getting the value of > intf.getAugmentation(ParentRefs.class). getVifType() and comparing > against InterfaceVifTypeVhostuser.class. If you notice the log, the > getVifType() returns the old value (*InterfaceVifTypeUnbound*) instead > of the value of updated content (*InterfaceVifTypeVhostuser*). > > > > > > Could anyone plz explain me if this is right way of using the MD-SAL > DCN notifications or a way to get around this intermittent error? > Thanks for your help. > > > > Thanks > > Srikanth > > > > > > > > _______________________________________________ > mdsal-dev mailing list > mdsal-...@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/mdsal-dev > _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
