-
Notifications
You must be signed in to change notification settings - Fork 889
feat: add debouncing to provisionerd rpc calls #5198
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
Conversation
f786491
to
5fc0c10
Compare
3993cec
to
e3d6f9b
Compare
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.
Not sure why it tagged me but scanned through code and nothing looks off 👍🏼
Seems to be BE only so dismissing just to be safe it's not accidentally merged
@@ -205,8 +211,8 @@ func (p *Server) connect(ctx context.Context) { | |||
if p.isClosed() { | |||
return | |||
} | |||
ticker := time.NewTicker(p.opts.PollInterval) | |||
defer ticker.Stop() | |||
timer := time.NewTimer(p.opts.JobPollInterval) |
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.
Wouldn't it be better to only apply this delay if it failed to acquire a job? This means we will acquire them as quick as possible without delays if there are a lot of jobs queued, but during periods of low jobs we will only attempt to acquire a job every 5 seconds.
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 guess in theory yeah, but it's currently architected in a way where this is still ticking while the provisioner is running a job, so it'd require a bit of a refactor for this to work.
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.
couldn't you just do something like:
for {
ok :=acquireJob()
if !ok {
select {
case <-ctx.Done():
return ctx.Err()
case <-time.After(5 * time.Second):
}
}
or something? time.After's only leak if they haven't fired yet, so since the interval is small and the only time this for loop will exit is if the app is shutting down it seems fine here
lastAcquireMutex.RLock() | ||
if !lastAcquire.IsZero() && time.Since(lastAcquire) < p.opts.JobPollDebounce { | ||
lastAcquireMutex.RUnlock() | ||
return | ||
} | ||
lastAcquireMutex.RUnlock() |
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.
Should disable this debounce if running in tests
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.
It's only enabled in coder server
coderd2
is running these changes