Add config_cassandra_client_test unit test to cover config_cassandra_client.cc
Add specific tests to cover fq-name and uuid-table from cassandra db.
Simulate many possible scenarios using parametertized gtests. code coverage
reports 94% for this file when all ifmap UTs are run including this new test
Fix request list corruption issue there by found while running this test.
In the current code, assumption is that the entry being deleted in
RemoveObjReqEntry() is always at the front of the uuid_read_list_. This is not
the case when (after bunching a few entries), we encounter delete/eor. In that
case, delete/eor could be any where in the middle/end of the list (as its
previous entries are still not processed). But by removing wrong head of the
list, we not only take wrong entry from the list we also end up deleted entry
to remain in the list. Code can crash later on, when this freed entry is
accessed.
This is fixed by storing list of iterators to the entries in the list, instead
of entries themselves. By this, we can still delete the entry in constant time
irrespective of where it is present in the list. (IOW, we still get pop()
equivalent semantics like how it is the current code)
Reviewed: https:/ /review. opencontrail. org/29617 github. org/Juniper/ contrail- controller/ commit/ aa800ba6d7e5004 5ac3777962dee3c 0c8fc40308
Committed: http://
Submitter: Zuul (<email address hidden>)
Branch: master
commit aa800ba6d7e5004 5ac3777962dee3c 0c8fc40308
Author: Ananth Suryanarayana <email address hidden>
Date: Wed Mar 15 12:47:09 2017 -0700
Add config_ cassandra_ client_ test unit test to cover config_ cassandra_ client. cc
Add specific tests to cover fq-name and uuid-table from cassandra db.
Simulate many possible scenarios using parametertized gtests. code coverage
reports 94% for this file when all ifmap UTs are run including this new test
Fix request list corruption issue there by found while running this test.
In the current code, assumption is that the entry being deleted in
RemoveObjReqEntry() is always at the front of the uuid_read_list_. This is not
the case when (after bunching a few entries), we encounter delete/eor. In that
case, delete/eor could be any where in the middle/end of the list (as its
previous entries are still not processed). But by removing wrong head of the
list, we not only take wrong entry from the list we also end up deleted entry
to remain in the list. Code can crash later on, when this freed entry is
accessed.
This is fixed by storing list of iterators to the entries in the list, instead
of entries themselves. By this, we can still delete the entry in constant time
irrespective of where it is present in the list. (IOW, we still get pop()
equivalent semantics like how it is the current code)
Change-Id: I66f6adb07eaf18 5e7fdbf9209b54b 382747e1621
Partial-Bug: #1632470