bosun: Concurrent checks #1231
bosun: Concurrent checks #1231
Conversation
|
Will fix #1228 |
| <-checkRunning | ||
| return d, err | ||
| } | ||
| //TODO: This makes less sense with every alert running independently. |
There was a problem hiding this comment.
This can just be yanked as a feature. The reason I created it was so when someone "fixed" an alert, they didn't have to wait for it to return to normal. But because queries cover a time range, this is generally pretty futile. My idea to actually fix this problem is delayed close as described in #808
|
@gbrayut, I would love a thorough review on this if you don't mind. |
| if s.notifications == nil { | ||
| s.notifications = make(map[*conf.Notification][]*State) | ||
| if s.pendingNotifications == nil { | ||
| s.pendingNotifications = make(map[*conf.Notification][]*State) |
There was a problem hiding this comment.
I'm not well versed in making maps or appending to them, but this smells like something that might need a lock or some other means of preventing duplicate assignments to the variable
There was a problem hiding this comment.
It does require locking. Anywhere this function is called the lock should be held. We are really bad at specifying those kinds of conventions though. This should almost certainly not be exported if that is the case, and should probably note that.
captncraig
force-pushed
the
concurrentChecks
branch
from
077c1eb to
dc0e51a
Compare
captncraig
force-pushed
the
concurrentChecks
branch
from
dc0e51a to
40a9704
Compare
This modifies the schedule in many ways. Each alert runs in its own goroutine.