-
Notifications
You must be signed in to change notification settings - Fork 0
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
[PAPAY-1395]: Explicitely shutdown the tracer provider #113
[PAPAY-1395]: Explicitely shutdown the tracer provider #113
Conversation
94760c1
to
d8e950c
Compare
|
||
let mut tracer_provider = TRACER_PROVIDER | ||
.lock() | ||
.expect("OpenTelemetry tracer provider mutex poisoned"); |
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.
What about gracefully handle the poison error recovering the old state?
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.
It can be poisoned if another thread panicked while it has the mutex locked. But this lock is used only 2 times, at startup and at shutdown.
At startup should not be possible to have a poisoned lock, because noone kept the lock before. At shutdown, it can be poisoned only if the startup panicked (precisely, if mem::replace(&mut *tracer_provider, Some(new_provider))
panicked). But in this case shutdown_tracer_provider
will not be called.
So, this seems a good case to use expect
, like done by opentelemetry::global::set_tracer_provider
...
|
||
let tracer_provider = TRACER_PROVIDER | ||
.lock() | ||
.expect("OpenTelemetry tracer provider mutex poisoned") |
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.
Same here
https://prima-assicurazioni-spa.myjetbrains.com/youtrack/issue/PAPAY-1395
After upgrading this library in our application, we observed the following errors logged after every execution of a scheduled tasks:
This is related to open-telemetry/opentelemetry-rust#1961.
It appears that we should explicitely shutdown the tracer provider, otherwise it doesn't flush all the data when the application terminates. Additionally, the process remains active and the Tokio' runtime complains.