-
Notifications
You must be signed in to change notification settings - Fork 264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix the issue of ignoring callback calls for removed keys. #811
Conversation
315f8be
to
c709e3a
Compare
c709e3a
to
4eabca4
Compare
This PR is a follow-up of #789 |
@@ -105,8 +105,11 @@ class ConfigDBConnector_Native : public SonicV2Connector_Native | |||
try: | |||
(table, row) = key.split(self.TABLE_NAME_SEPARATOR, 1) | |||
if table in self.handlers: | |||
client = self.get_redis_client(self.db_name) | |||
data = self.raw_to_typed(client.hgetall(key)) | |||
if item['data'] == 'del': |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@qiluo-msft done. Please review
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run Azure.sonic-swss-common |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
@qiluo-msft kindly reminder. Please review the changes. |
…#811) **What I did** Fix the issue of ignoring callback calls for removed keys. **Why I did it** ConfigDBConnector.listen method has a caching mechanism (added in sonic-net#587 PR) that preloads the DB state before starting. When the notification about the changed key is received the listen method gets key data from the DB (in all cases when the key was added, updated, or removed) and compares the data with the cache. It fires the callback only if data differ from the cache. Otherwise, the callback is ignored. If the `client.hgetall(key)` is called for the removed key it returns an empty dictionary (`{}`). This can be confused with the data of the key with no attributes. For example: `{"TABLE": {"KEY": {}}}`. So if preloaded data contains a key with no attributes and the listener method receives a notification about the removal of such key the callback is not called. The listener will simply remove the key from the cache without calling the callback. This leads to the situation when the removal of the key is not handled. The solution is to get data for the added or updated keys, and for the removed keys use `None` instead. This will ensure that the comparison with the cache will work as expected. **How I verified it** Compile the package and run the unit test. Unit tests are extended to cover the expected behavior.
What I did
Fix the issue of ignoring callback calls for removed keys.
Why I did it
ConfigDBConnector.listen method has a caching mechanism (added in #587 PR) that preloads the DB state before starting. When the notification about the changed key is received the listen method gets key data from the DB (in all cases when the key was added, updated, or removed) and compares the data with the cache. It fires the callback only if data differ from the cache. Otherwise, the callback is ignored.
If the
client.hgetall(key)
is called for the removed key it returns an empty dictionary ({}
). This can be confused with the data of the key with no attributes. For example:{"TABLE": {"KEY": {}}}
.So if preloaded data contains a key with no attributes and the listener method receives a notification about the removal of such key the callback is not called. The listener will simply remove the key from the cache without calling the callback. This leads to the situation when the removal of the key is not handled.
The solution is to get data for the added or updated keys, and for the removed keys use
None
instead. This will ensure that the comparison with the cache will work as expected.How I verified it
Compile the package and run the unit test. Unit tests are extended to cover the expected behavior.
Details if related