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

Expose static RuntimeContext storage for lifecycle management #1211

Closed
westonpace opened this issue Feb 14, 2022 · 0 comments · Fixed by #1214
Closed

Expose static RuntimeContext storage for lifecycle management #1211

westonpace opened this issue Feb 14, 2022 · 0 comments · Fixed by #1214
Assignees
Labels
enhancement New feature or request

Comments

@westonpace
Copy link

westonpace commented Feb 14, 2022

Before opening a feature request against this repo, consider whether the feature should/could be implemented in the other OpenTelemetry client libraries. If so, please open an issue on opentelemetry-specification first.

Is your feature request related to a problem?
I am working on the Apache Arrow project and this is related to an issue we have: ARROW-15604

The problem is that Arrow has a thread pool stored in its own static state. We create spans in tasks that run on that thread pool. At shutdown, there is no way to control which static state gets destroyed first. Usually it is OpenTelemetry's state that is destroyed first because the thread pool tries to wait until its worker threads have finished. Those worker threads are usually finishing up tasks and, at the end, destroy a scope. The scope's destructor attempts to access the static runtime context storage but it has already been destroyed.

We can work around this by initializing the runtime context storage ourselves and using opentelemetry::context::RuntimeContext::SetRuntimeContextStorage but this is only a workaround because we are a library and not an application so we risk overriding the user's runtime context storage. Instead we'd like to be able to make a copy of OTel's shared pointer so that we can keep it alive until our threads finish.

Describe the solution you'd like
If the method opentelemetry::context::RuntimeContext::GetRuntimeContextStorage() were public that would solve our problem.

Describe alternatives you've considered
I think we're open to any alternatives that we can use to extend the lifetime of the runtime context storage.

Additional context
I've created a simple reproduction of this issue here: https://github.com/westonpace/otel-storage-accessor-repr

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants