-
Notifications
You must be signed in to change notification settings - Fork 107
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: concurrent map iteration and map write #727
Conversation
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.
Thanks for the fix! ❤️
Could you update changelog as well?
for key, val := range r.countMap { | ||
cts.Counts[key] = val | ||
} |
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.
Aren't we just moving the concurrency conflicts just to here? Should we use a mutex to protect this code? @t0rr3sp3dr0 WDYT?
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.
This should be fine. The problem is that we were passing the reference of the internal Queue map, that is protected by a mutex, to the Counts struct, that is not aware of the mutex. So when someone interacted with the Counts struct, the internal Queue map was being used without locking the mutex. Now the map is being copied to the Counts struct, fixing the problem.
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.
The Counts struct is not thread-safe and its instances are not being accessed by multiple routines, so we don’t need a mutex that side.
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.
@luckymrwang, to prevent regressions in the future, can you implement a test to make sure the Current method always returns a copy of the internal map and not a reference to it? Given we are now returning a new map, it’s a good idea to also test if the Counts map contains the same values as the Queue map.
@t0rr3sp3dr0 Ok, I will add it later. |
Hi @luckymrwang , |
@JorTurFer @t0rr3sp3dr0 I was busy the past two days and the latest code has been committed. |
Statics checks are faillig, could you review them and update changelog as well? |
@JorTurFer The latest code has been committed. |
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.
Please, add a note in the changelog about this PR: https://github.com/kedacore/http-add-on/blob/main/CHANGELOG.md#fixes
pkg/queue/queue_test.go
Outdated
|
||
err = memory.Resize("host1", 1) | ||
r.NoError(err) | ||
memory.Resize("host2", 1) |
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.
memory.Resize("host2", 1) | |
err = memory.Resize("host2", 1) |
Signed-off-by: Cookie Wang <[email protected]>
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.
LGTM! Thanks for the fix ❤️
PTAL @t0rr3sp3dr0
lgtm |
Signed-off-by: Jorge Turrado <[email protected]>
Provide a description of what has been changed
Checklist
README.md
docs/
directoryFixes #726