-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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 races in CQ execution #2553
Conversation
9555750
to
e86ebb0
Compare
These races were flagged here: |
@@ -3955,6 +3953,18 @@ func (s *Server) runContinuousQuery(cq *ContinuousQuery) { | |||
cq.mu.Lock() | |||
defer cq.mu.Unlock() | |||
|
|||
// Get server CQ parameters under lock, to avoid races. | |||
s.mu.RLock() |
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.
do we really need to lock on these? They can't ever get updated on a running process. They're set when the server object is created and never set again.
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.
Perhaps not. This may be rather pedantic. This was a drive-by change -- the real race is around lastRun
which was being written and read from different goroutines.
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.
I can pull this change. I agree that these settings never change.
yeah, this seems sane to me, even if it only could ever fail during testing. +1 |
This change refactors the CQ code such that "should run" is checked within the goroutine that the CQ will run, if it does run. This avoids the race, at the cost a very-short lived goroutine if the CQ is not run.