3 ms·

The java implementation seems to lean on trying to pass context objects around implicitly as a ThreadLocal. This will cause pain and suffering in the presence

The java implementation seems to lean on trying to pass context objects around implicitly as a ThreadLocal. This will cause pain and suffering in the presence of async, multithreaded code: your trace context will be present in the thread where your request handler began, but won't be present in threads running callbacks from non-blocking IO libraries (netty, akka-http, async-http-client, redisson, etc).

svcrunch 6y ago
For Java, what's the advantage of using this library, versus directly using JMX? Are the abstractions better? I took a look at the documentation and it wasn't clear to me.
- jkwatson 6y ago
  Maintainer of the java implementation here. OpenTelemetry is really orthogonal to JMX. We're trying to provide a standard way to capture spans (traces) and metrics and send them to observability systems, both open source and vendor-provided. Those metrics might originate from JMX, or any other source of metrics you might have. Our APIs do provide a way to directly capture metrics, but also to hook into existing metric providers (like JMX or JFR).
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 ago
  When 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.
jeffbee 6y ago
Async style is not incompatible with storing the trace context in thread-local storage. You just capture the trace context when you create the callback. That's how Dapper works, in C++ and Java. See section 2.2 of the Dapper paper. https://storage.googleapis.com/pub-tools-public-publication-data/pdf/36356.pdf https://storage.googleapis.com/pub-tools-public-publication-...
- aphexairlines 6y ago
  From that section: "most Google developers use a common control flow library to construct callbacks" OpenTelemetry can't guarantee that their users will use a specific library to create callbacks and can't then ensure that this library wraps callbacks with the appropriate threadlocal setup. Users would by default run into problems unless they take a number of precautionary steps.

svcrunch 6y ago

For Java, what's the advantage of using this library, versus directly using JMX? Are the abstractions better? I took a look at the documentation and it wasn't clear to me.

jkwatson 6y ago
Maintainer of the java implementation here. OpenTelemetry is really orthogonal to JMX. We're trying to provide a standard way to capture spans (traces) and metrics and send them to observability systems, both open source and vendor-provided. Those metrics might originate from JMX, or any other source of metrics you might have. Our APIs do provide a way to directly capture metrics, but also to hook into existing metric providers (like JMX or JFR).

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 ago
When 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.

jeffbee 6y ago

Async style is not incompatible with storing the trace context in thread-local storage. You just capture the trace context when you create the callback. That's how Dapper works, in C++ and Java. See section 2.2 of the Dapper paper. https://storage.googleapis.com/pub-tools-public-publication-data/pdf/36356.pdf https://storage.googleapis.com/pub-tools-public-publication-...

aphexairlines 6y ago
From that section: "most Google developers use a common control flow library to construct callbacks" OpenTelemetry can't guarantee that their users will use a specific library to create callbacks and can't then ensure that this library wraps callbacks with the appropriate threadlocal setup. Users would by default run into problems unless they take a number of precautionary steps.