Skip to content
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

We should update and start the ticker metrics before we return from an error. #64

Merged
merged 3 commits into from
Oct 15, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 5 additions & 4 deletions ring/ring.go
Original file line number Diff line number Diff line change
Expand Up @@ -276,14 +276,14 @@ func (r *Ring) starting(ctx context.Context) error {
if err != nil {
return errors.Wrap(err, "unable to initialise ring state")
}
if value == nil {
if value != nil {
r.updateRingState(value.(*Desc))
} else {
level.Info(r.logger).Log("msg", "ring doesn't exist in KV store yet")
return nil
}

r.updateRingState(value.(*Desc))
// Update the ring metrics at start.
r.updateRingMetrics()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to approve it to unblock you, but my point (that I tried to mention offline on Slack) is that given we haven't called updateRingState() yet at this point, I see useless calling updateRingMetrics() here. Why do we need it? Shouldn't we call updateRingMetrics() after updateRingState() below in the function?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the ordering in this PR to reflect this. Yeah, I see what you mean, we should attempt to update the ring state before updating the ring metrics for the case where we do actually get something back from the kv store. I'm going to merge this PR to unblock myself and do a refactor to move this to loop which will also solve this problem.


// Use this channel to close the go routine to prevent leaks.
r.metricsUpdateCloser = make(chan struct{})
go func() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I remember correctly the service framework, if starting returns an error, the stopping won't be called. Could you double check it? If confirmed, then we should start the ticker at last, otherwise we'll leak the goroutine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't look like we do, I'll fix that here, but it that something we should make a issue for in basic services?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is already starting goroutine as last thing in starting, it looks good to me.

Copy link
Member

@pstibrany pstibrany Oct 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can also start it in loop, and make metricsUpdateCloser scoped to loop only. That would actually solve the original problem in this method as well (early return when value was nil).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took a look at some services in cortex proper and using the loop function for starting the ticker and using the context to exit is our common pattern. I'm going to move to that pattern for this ticker here as well.

Expand All @@ -300,6 +300,7 @@ func (r *Ring) starting(ctx context.Context) error {
}
}
}()

return nil
}

Expand Down