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

[Refactor]: Remove the use of channels to signal healthcheck status #5307

Closed
WillSewell opened this issue Mar 28, 2024 · 2 comments · Fixed by #5308
Closed

[Refactor]: Remove the use of channels to signal healthcheck status #5307

WillSewell opened this issue Mar 28, 2024 · 2 comments · Fixed by #5308

Comments

@WillSewell
Copy link
Contributor

Requirement

As a contributor who has been attempting to fix goroutine leaks in tests it would be easier to manage gorotoutine cleanup on server close if healthcheck reporting between the server and service did not rely on channels.

Problem

As discussed in https://github.com/jaegertracing/jaeger/pull/5299/files#diff-b4a37944a109260d3630b973cdae2dc012d6bc67134efa50397976f713630e08, a significant source of complexity and risk of deadlocks comes from the use of a channel to signal server healthcheck status back to the server.

Proposal

Instead of using a channel, pkg/healthcheck is already thread safe, and we currently don't have any need for components to "subscribe" to healthcheck status, so instead of writing to a channel and having a consumer update the pkg/healthcheck, I think we could just update the state from the server directly.

Open questions

I'm not sure whether we should completely decouple the server from the healthcheck package, by passing in a callback to update healthcheck status. The alternative would be to just pass a *healthcheck.Healthcheck directly to the server.

Pros of callback: gives the caller more control - e.g. they could use a channel if they wanted to
Cons: inconsistent with how the *healthcheck.Healthcheck is passed directly to the collector component (example), I also think it's a bit more complex due to indirection.

Currently I'm leaning towards passing a *healthcheck.Healthcheck because there's currently no need for anything more flexible - e.g. the ability to subscribe to changes - and I think if this ever was required it's something that could be built into the healthcheck package.

WillSewell pushed a commit to WillSewell/jaeger that referenced this issue Mar 28, 2024
Simplifies the signalling of healthcheck status from the "servers"
to the "service": instead of using 2 channels to feed healthcheck
status back to the Service.HealthCheck, we just give the server
components direct access to the Healthcheck which they can update
directly. This is possible because the Healthcheck package is
threadsafe (uses `atomic.Value` for state).

This pattern is consisten with how the service's Healtcheck is
passed directly to cmd/collector/app package.

closes jaegertracing#5307

Signed-off-by: Will Sewell <[email protected]>
@WillSewell
Copy link
Contributor Author

I took the "pass directly" approach here: #5308. Interested to get your thoughts @yurishkuro as it's a bit different to the callback approach you mentioned.

@yurishkuro
Copy link
Member

passing directly is ok. The alternative would be to just pass the function hc.Set so that other components would only be exposed to the function signature, not to the whole HC class. That's exactly what OTEL status reporting mechanism does.

yurishkuro added a commit that referenced this issue Mar 28, 2024
## Which problem is this PR solving?
Resolves #5307

## Description of the changes
- Simplifies the signalling of healthcheck status from the "servers" to
the "service": instead of using 2 channels to feed healthcheck status
back to the Service.HealthCheck, we just give the server components
direct access to the Healthcheck which they can update directly.
- This is possible because the Healthcheck package is threadsafe (uses
`atomic.Value` for state).
- This pattern is consistent with how the service's Healtcheck is passed
directly to cmd/collector/app package.

## How was this change tested?
- `make lint test`

## Checklist
- [x] I have read
https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md
- [x] I have signed all commits
- [ ] I have added unit tests for the new functionality
- [x] I have run lint and test steps successfully
  - for `jaeger`: `make lint test`
  - for `jaeger-ui`: `yarn lint` and `yarn test`

---------

Signed-off-by: Will Sewell <[email protected]>
Signed-off-by: Yuri Shkuro <[email protected]>
Co-authored-by: Yuri Shkuro <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants