Additional documentation

[benmccann]

The readme says this package instruments ExecutorService, Executor, Runnable, and Callable, but it only gives an example for ExecutorService. Is the only entry point ExecutorService? Or is there something you would do to directly instrument Executor, Runnable, and Callable?

Also, I'm wondering how these calls will be show up when looking at the trace. E.g. Parseq tracing does a really good job at showing you the line number and method where each span occurred. Does this package have any ability to appropriately name each span automatically or to allow the user to create their own name for each span? It would be really helpful to see what a trace using this package looks like

[objectiser]

Hi @benmccann

Sorry for the very long delay in answering your question.

This library does not actually create spans - it is only responsible for propagating the trace context between units of work that may be performed in separate threads.

Various framework instrumentation libraries are available, some under this opentracing-contrib org, that do create spans - and some provide mechanisms for customising the span names that are used. It would be worth you trying out some of those instrumentations to see whether they provide the functionality you require and if not raising an issue on those repos.

Thanks - and sorry again for the long delay in responding.

I'll keep this issue open for now, to review the current readme for improvements.

[benmccann]

Ah. I was looking for something that would help me see where the time was being spent in a web service where there can be some compute-heavy calls. Open tracing helps accomplish 90% of this today by instrumenting network calls which normally take most of the time, but it would be nice to be able to instrument the Java concurrent classes for code where CPU may take as much time as network calls.

[objectiser]

@benmccann Sounds like it could be a useful feature - although probably would need to be configurable and disabled by default, as could bloat the trace instances. Could you create a separate issue for the feature request?