-
Notifications
You must be signed in to change notification settings - Fork 384
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
feat(logs): make logger shutdown &self #1643
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1643 +/- ##
=======================================
+ Coverage 69.3% 70.0% +0.7%
=======================================
Files 136 136
Lines 19637 20029 +392
=======================================
+ Hits 13610 14028 +418
+ Misses 6027 6001 -26 ☔ View full report in Codecov by Sentry. |
This seems like a much more streamlined approach. In particular, the LoggerProvider (and so the LogProcessors) can be shut down without needing to wait for all loggers to be dropped.
I believe it should be acceptable if the check is performed atomically. This isn't related to the current PR, but just to reiterate so I don't forget, this check would also need to be added in ReentrantLogProcessor for ETW and user_events exporter. |
@TommyCpp Do you plan to make it ready for review? The changes look good to me. |
Sorry busy week. Will get it done this weekend |
I think we should also make it clear that |
} | ||
|
||
/// Attempts to shutdown this `LoggerProvider`, succeeding only when | ||
/// all cloned `LoggerProvider` values have been dropped. | ||
// todo: remove this |
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.
nit - If we are keeping try_shutdown()
for backward compatibility, good to update the existing comments, as now it doesn't just attempt, but really shutdown the LoggerProvider.
1b45663
to
52757f0
Compare
Simple log processor took some hit as expected but it's acceptable IMHO
|
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.
Thanks.
5631a88
to
a0c0dbf
Compare
@open-telemetry/rust-approvers can I get another review? |
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.
This is probably not required for logging signal...
See https://github.com/open-telemetry/opentelemetry-rust/pull/1643/files#r1579840322
fc907ff
to
0fcd167
Compare
opentelemetry-sdk/CHANGELOG.md
Outdated
@@ -13,6 +13,7 @@ | |||
`ProcessResourceDetector` resource detectors, use the | |||
[`opentelemetry-resource-detector`](https://crates.io/crates/opentelemetry-resource-detectors) instead. | |||
- Baggage propagation error will be reported to global error handler [#1640](https://github.com/open-telemetry/opentelemetry-rust/pull/1640) | |||
- Make `shutdown` method in `LoggerProvider` and `LogProcessor` taking immutable reference [#1643](https://github.com/open-telemetry/opentelemetry-rust/pull/1643) |
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.
Lets describe all the changes this PR is making:
- Loggers obtained after shutdown is now no-ops.
- Shutdown requires immutable ref for provider/processor.
- Simple and batch processors will ignore new logrecord after shutdown.
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.
Thanks! I have a suggestion to make changelog better to reflect the actuals.
Also please update the PR description to reflect the current state, for easy paper-trail in the future.
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.
Thanks.
This PR aim to address the issue brought up in #1625 (comment)
In summary we need to:
We discussed the solution of keeping
Weak
reference fromLoggerProvider
toLogger
s but as I implemented this solution it seems to complicated. I revisited why we need mutable reference duringLoggerProvider
and found thatLogProcessor
shutdown doesn't have to take a mutable reference.Changes
make
LogProcessor
shutdown taking&self
instead of&mut self
.shutdown
fromdrop
. If oneLogProcessor
is shared across multiple thread, any thread can callshutdown
to stop theLogProcessor
from emitting more logs. But this doesn't mean theLogProcessor
will drop.drop
will callshutdown
shutdown
inBatchLogProcessor
. Emitting new logs after shutdown will result in aLogError
saying the receiver on the worker task has already closed.SimpleLogProcessor
we need a field to mark if the processor has been shutdown we also need to check it everytime before emitting the logs.Add a field in
LoggerProvider
to mark if the logger provider has shutdown. If it has, return a noop loggerMerge requirement checklist
CHANGELOG.md
files updated for non-trivial, user-facing changes