-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[pkg/stanza] Overhaul reader management #27823
[pkg/stanza] Overhaul reader management #27823
Conversation
@VihasMakwana, I've mentioned previously a need to simplify the way we manage readers, which should in turn simplify the design of your proposal. I believe I finally have substantial step in the right direction. This does not immediately enable your changes but I think it is a good start towards narrowing the problem which asynchronous polling must solve. I plan to break this into smaller PRs but I'd welcome your careful review of these preliminary changes. |
817cdd4
to
e415be8
Compare
01f939b
to
d6db185
Compare
d6db185
to
8d613f1
Compare
This PR is currently ready but I've moved it back to a draft because I think it could be made less complex but pulling a few changes into smaller PRs. |
33e8475
to
dbf5c87
Compare
Follows #28419 This discards the separate "roller" and implements the same functionality directly in `fileconsumer.Manager`. The motivation for this is to move towards a system of managing files where each file is managed by only one list at a time. This PR retains two overlapping slices of readers (`previousPollFiles` and `knownFiles`), but the functionality does not change. #27823 should get us the rest of the way there.
6f361cd
to
e4df8ba
Compare
98c8f32
to
a4fe142
Compare
a4fe142
to
be9ffed
Compare
I've opened #27823 to extract one additional small subset of changes from this PR. |
Although the persister is generally expected, we can easily protect against cases where it is not provided and save some work as well. This becomes more important with #27823 which interacts with the persister during the Stop function.
dd70dc5
to
72f421f
Compare
This is ready for a proper review now. |
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.
Looks good. This will surely help our problem with the asynchronous solution.
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.
The changes look decent, however, are the changes covered by existing test cases?
…metry#28451) Follows open-telemetry#28419 This discards the separate "roller" and implements the same functionality directly in `fileconsumer.Manager`. The motivation for this is to move towards a system of managing files where each file is managed by only one list at a time. This PR retains two overlapping slices of readers (`previousPollFiles` and `knownFiles`), but the functionality does not change. open-telemetry#27823 should get us the rest of the way there.
…28580) Although the persister is generally expected, we can easily protect against cases where it is not provided and save some work as well. This becomes more important with open-telemetry#27823 which interacts with the persister during the Stop function.
Thanks for the review @MovieStoreGuy.
I think we have pretty good coverage for overall functionality. However, this change is in part motivated by the need to simplify and decompose the package in order to make it more testable. |
…metry#28451) Follows open-telemetry#28419 This discards the separate "roller" and implements the same functionality directly in `fileconsumer.Manager`. The motivation for this is to move towards a system of managing files where each file is managed by only one list at a time. This PR retains two overlapping slices of readers (`previousPollFiles` and `knownFiles`), but the functionality does not change. open-telemetry#27823 should get us the rest of the way there.
…28580) Although the persister is generally expected, we can easily protect against cases where it is not provided and save some work as well. This becomes more important with open-telemetry#27823 which interacts with the persister during the Stop function.
- Change `knownFiles` to `[]*reader.Metadata`. No files are held here. - Introduce new `previousPollReaders` list, which holds open files from the previous poll interval. If for any reason a file is closed, it should immediately be removed from the list and its metadata should be added to `knownFiles`. - Introduce notion that each `reader.Metadata` should be treated as a singleton. When a reader is closed, it pops out its `Metadata` so it can be appended to `knownFiles`.
…28580) Although the persister is generally expected, we can easily protect against cases where it is not provided and save some work as well. This becomes more important with open-telemetry#27823 which interacts with the persister during the Stop function.
- Change `knownFiles` to `[]*reader.Metadata`. No files are held here. - Introduce new `previousPollReaders` list, which holds open files from the previous poll interval. If for any reason a file is closed, it should immediately be removed from the list and its metadata should be added to `knownFiles`. - Introduce notion that each `reader.Metadata` should be treated as a singleton. When a reader is closed, it pops out its `Metadata` so it can be appended to `knownFiles`.
knownFiles
to[]*reader.Metadata
. No files are held here.previousPollReaders
list, which holds open files from the previous poll interval. If for any reason a file is closed, it should immediately be removed from the list and its metadata should be added toknownFiles
.reader.Metadata
should be treated as a singleton. When a reader is closed, it pops out itsMetadata
so it can be appended toknownFiles
.