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

Lifecycle refactor #190

Merged
merged 7 commits into from
Feb 10, 2022
Merged

Lifecycle refactor #190

merged 7 commits into from
Feb 10, 2022

Conversation

jmwilliams89
Copy link
Contributor

Proposed Change

  • Updated to otel collector 0.44
  • Added Mongodb receiver
  • Fixed bug with collector startup
Checklist
  • Changes are tested
  • Changes are documented

@jmwilliams89 jmwilliams89 requested a review from a team as a code owner February 9, 2022 21:38
Copy link
Contributor

@cpheps cpheps left a comment

Choose a reason for hiding this comment

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

Overall looks good I don't see anything that blocks this merge more just questions for my edification.

configPath: configPath,
version: version,
loggingOpts: loggingOpts,
statusChan: make(chan *Status, 10),
Copy link
Contributor

Choose a reason for hiding this comment

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

Any reason we chose 10 here?

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 was an arbitrary selection related to the select statement below. I wanted to give a wide enough buffer that if something was listening to the status channel, it minimized the risk of missing something if it wasn't consuming fast enough.

version: version,
loggingOpts: loggingOpts,
statusChan: make(chan *Status, 10),
wg: &sync.WaitGroup{},
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: usually wait groups are not pointers unless passed into functions. I have no idea why honestly more of just an observation you don't have to change it.

select {
case c.statusChan <- status:
case c.statusChan <- &Status{running, err}:
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this in a select? Is it just so we don't block sending? Seems like we could miss a send if the channel is full. Maybe that's ok?

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 went with this pattern, because I didn't think there were any guarantees that whoever is using this struct is listening to the status channel. So I didn't want to lock everything up on a full channel, in the scenario where there is no consumer.


service:
pipelines:
logs:
receivers: [filelog]
exporters: [logging]
exporters: [nop]
Copy link
Contributor

Choose a reason for hiding this comment

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

nit newline (you can thank Duri for me noticing missing newlines on files)


service:
pipelines:
logs:
receivers: [filelog]
exporters: [logging]
exporters: [nop]
Copy link
Contributor

Choose a reason for hiding this comment

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

newline

@jsirianni
Copy link
Member

Tests detected a race condition, and lots of this in ci-check

ill.Logs is deprecated: use `LogRecords`. (staticcheck)

@jmwilliams89 jmwilliams89 merged commit fe387c7 into master Feb 10, 2022
@jmwilliams89 jmwilliams89 deleted the lifecycle-refactor branch February 10, 2022 17:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants