3 ms·
Java implementation maintainer here. Our context propagation story is still evolving and under active development. We are hyper-aware of the issues with managi
by jkwatson 6y ago
Java implementation maintainer here.
Our context propagation story is still evolving and under active development. We are hyper-aware of the issues with managing propagation with asynchronous contexts, and are working on building a solution that instrumentation authors can use to manage the propagation of context both synchronous and asychronous. If you have expertise in this area, we would love help and feedback on what we're building!
- aphexairlines 6y agoWhen we integrated async jvm (scala) services with another tracing provider, we took two approaches. One was to pass the trace context down from the request handler through anything that would declare a span or need to send trace headers down to another service. The other was to instantiate service clients per request, and pass the trace context into the service client constructor.
- brown9-2 6y ago> building a solution that instrumentation authors can use to manage the propagation of context both synchronous and asychronous The bigger problem I’ve had - with OpenCensus - is managing the context within my application using async code, where I want to add interior spans and also call libraries which are creating spans themselves. Do your plans include these scenarios? Am I an “instrumentation author” here? There is really no way to make anything related to ThreadLocals work with “async” code, and the simplest most reliable solution we have found is to treat the Context as a method parameter. Looking at https://github.com/open-telemetry/opentelemetry-java/issues/575 https://github.com/open-telemetry/opentelemetry-java/issues/... I worry that more layers of indirection will be added, not less.