You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an application has subscribed for notifications and a large batch of notifications should theoretically be available, it appears as though the notifications "trickle in" to the application from the underlying Redis connection (~10 per second), rather than being received in a single, large batch.
@qiluo-msft: @abdosi converted caclmgrd to use swsscommon. Could you also please provide an example of another application which "keeps pop() until you get empty result"?
@abdosi: Have you confirmed that this is not actually an issue with swss-common, but rather with the way you were using it? If so, I will close this issue.
In my experiment for the configuration where we just dump x rules all x notification are present in select object queue withy no delay and we are processing them continuously.
I feel my experiment proves there is no delay in swsscommon . Do you want any particular test to run ?
I am also planning to let Mellanox QA person to test with this change and let us know.
When an application has subscribed for notifications and a large batch of notifications should theoretically be available, it appears as though the notifications "trickle in" to the application from the underlying Redis connection (~10 per second), rather than being received in a single, large batch.
This behavior was noticed while debugging an issue with caclmgd here: sonic-net/sonic-buildimage#5275
The text was updated successfully, but these errors were encountered: