[CONTROLLER-220] DataChange even is inconsistent with changes in the data store via Restconf Created: 20/Mar/14  Updated: 25/Jul/23  Resolved: 19/May/14

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

Type: Bug
Reporter: Zoltan Lajos Kis Assignee: Tony Tkacik
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC

Attachments: File restconftest.tar.gz    
Issue Links:
Duplicate
is duplicated by CONTROLLER-241 Topology data change event does not p... Resolved
External issue ID: 554
Priority: High

 Description   

I'm trying to provide a configuration facility to my bundle, where the configuration state can be updated over the Restconf interface, and my code reacts to those changes via onDataChange events.

I would like to raise that the current DataChange events are quite counter-intuitive to use. While practically it is possible to deduce what happened, it would be more convenient if the reported maps/sets contained only what their name suggests.

1) When a new configuration element is created, it appears both as "created" and "updated". It would be more convenient if created elements would only be reported as "created".

2) When a configuration element is updated with identical data (i.e., did not change), it is still reported as "updated". It would be useful if such identical updates were filtered by the data store internals, and would not be reported to the listeners.

3) When a configuration element is deleted, it is not reported as "removed"; it only appears among the "original" elements. It would be useful if was contained among the "removed" elements as well.

I have attached a bundle which can be used to reproduce what happens. Check the readme.txt file for details.

 Comments   
Comment by Zoltan Lajos Kis [ 20/Mar/14 ]

Attachment restconftest.tar.gz has been added with description: bundle to reproduce the bug

Comment by Harman Singh [ 27/Mar/14 ]

The similar issues are seen when I try to listen the data change event on Topology changes.

If you register listener for Links like following -

dataService.registerDataChangeListener(
InstanceIdentifier.builder(NetworkTopology.class).child(Topology.class, new TopologyKey(new TopologyId("flow:1")))
.child(Link.class).toInstance(), new TopologyListener());

Where my TopologyListener class, which implements DataChangeListener looks like following -

public class TopologyListener implements DataChangeListener{

@Override
public void onDataChanged(
DataChangeEvent<InstanceIdentifier<?>, DataObject> change)

{ Map<InstanceIdentifier<?>, DataObject> linkCreated = change.getCreatedOperationalData(); Set<InstanceIdentifier<?>> linkRemoved = change.getRemovedOperationalData(); }

Now, whenever a new link is removed, change.getRemovedOperationalData() does not have data, its empty Set. That information should be available.

Comment by Tony Tkacik [ 08/Apr/14 ]

I am trying to listen to MD-SAL topology changes, specifically creation and removal of links.
Other steps to reproduce (from CONTROLLER-241)

I register my listener for Links like following -

dataService.registerDataChangeListener(
InstanceIdentifier.builder(NetworkTopology.class).child(Topology.class, new TopologyKey(new TopologyId("flow:1")))
.child(Link.class).toInstance(), new TopologyListener());

Where my TopologyListener class, which implements DataChangeListener looks like following -

public class TopologyListener implements DataChangeListener{

@Override
public void onDataChanged(
DataChangeEvent<InstanceIdentifier<?>, DataObject> change)

{ Map<InstanceIdentifier<?>, DataObject> linkCreated = change.getCreatedOperationalData(); Set<InstanceIdentifier<?>> linkRemoved = change.getRemovedOperationalData(); }

Now, when a link is removed, change.getRemovedOperationalData() does not have data, its empty Set.

Comment by Tony Tkacik [ 19/May/14 ]

Data Change Events were fixed at master over last 3 weeks.

This behaviour should be fixed.

Generated at Wed Feb 07 19:52:29 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.