[CONTROLLER-1410] After controller reboot, applications don't receive data change notification with the blob of persisted config data Created: 24/Aug/15  Updated: 19/Oct/17  Resolved: 01/Sep/15

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

Type: Bug
Reporter: Anil Vishnoi Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File karaf.first.start.log     Text File karaf.reboot.log    
Issue Links:
Duplicate
duplicates CONTROLLER-1399 Clustering: DCN varies in normal and ... Verified
External issue ID: 4179

 Description   

As per my understanding, when controller restarts, application subscribed for data change notification should get a notification with a blob of data that was persisted before the shutdown. OVSDB southbound plugins is not getting the data change notification with the persisted config data after controller reboots.

Following are the easy steps that you can use to recreate the issues, but i believe you can try with any yang model and probably see the same issue (although i didn't try it ).

1) git clone https://git.opendaylight.org/gerrit/ovsdb.git
2) cd ovsdb
3) mvn clean install -DskipTests
4) cd ./karaf/target/assembly/bin
5) ./karaf debug
6) wait for controller console to come up
7) karaf#> log:set TRACE org.opendaylight.ovsdb.southbound.OvsdbDataChangeListener

8) wait for all the ovsdb component to come up, you will see "triggerUpdate()" line in the log file.
9)Fire following PUT restconf request to the controller (url and body are in following gist link)
https://gist.github.com/vishnoianil/3ed803e9fb7e56d29a63

10) Once you PUT this restconf request, you should see data change dump in the log. Something like this
https://gist.github.com/vishnoianil/c8204224ab30d06ee408

11) Now reboot the controller and you won't see any dump from data change notificaiton.

12) BUT you will see data still persist in the config data store. You can fire following restconf request to get the data

GET: http://localhost:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1

13) This is how we are doing the registration:
https://github.com/opendaylight/ovsdb/blob/master/southbound/southbound-impl/src/main/java/org/opendaylight/ovsdb/southbound/OvsdbDataChangeListener.java#L55

14) This is where ovsdb is dumping the data change notification data:
https://github.com/opendaylight/ovsdb/blob/master/southbound/southbound-impl/src/main/java/org/opendaylight/ovsdb/southbound/OvsdbDataChangeListener.java#L72

I am attaching the log for your reference.

karaf.first.start.log – contains log from the first start and adding one entry to config data store
karaf.reboot.log – contains log after reboot.

Let me know if you need more data or live debug this issue.



 Comments   
Comment by Anil Vishnoi [ 24/Aug/15 ]

Attachment karaf.first.start.log has been added with description: Log of first start and config entry addition

Comment by Anil Vishnoi [ 24/Aug/15 ]

Attachment karaf.reboot.log has been added with description: Log after reboot

Comment by Anil Vishnoi [ 24/Aug/15 ]

I see this issue on both stable/lithium and master branch.

Comment by Muthukumaran Kothandaraman [ 25/Aug/15 ]

We see this for specific datastructures on stable/lithium, See this CONTROLLER-1399. Are you seeing this type of behavior or DCN does not come consistently across the board ?

Comment by Anil Vishnoi [ 25/Aug/15 ]

i see this behavior consistently, but i didn't try the same thing for other listener. I see this issue with this listener registration

InstanceIdentifier<Node> path = InstanceIdentifier
.create(NetworkTopology.class)
.child(Topology.class, new TopologyKey(SouthboundConstants.OVSDB_TOPOLOGY_ID))
.child(Node.class);
registration =
db.registerDataChangeListener(LogicalDatastoreType.CONFIGURATION, path, this, DataChangeScope.SUBTREE);

I think CONTROLLER-1399 also reports the similar issue.

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