Regression in ExecutorInstrumentation v0.7.0? about dd-trace-java HOT 2 CLOSED

Hi @mwirges, yes it is intentional that the flag be set. However we can explore some options to make things more smooth on your end.

First, some context. Propagating our trace by default can cause problems because the executor instrumentation is too low level to know where to start and stop automatically. This sometimes causes traces to be linked across logical boundaries. We've seen http servers with code like this:

writeResponseToUser(response);
// the executor instrumentation will link this call to submit
// causing the two requests to be captured under the same trace
threadPool.submit(processNextRequestCallback);

To avoid this issue we're using higher level instrumentation to turn the async instrumentation on and off at the appropriate times.

For example, in play we enable async instrumentation when the request comes in and disable when the response goes out.

Setting this flag does not require a dependency on dd-trace-ot, just on dd-trace-api, which is a smaller library with no transitive dependencies. https://mvnrepository.com/artifact/com.datadoghq/dd-trace-api/0.7.0

As a solution, we can add async logic to our builtin servlet instrumentation similar to what we do with play. That will give you the old behavior when using async libraries inside a servlet request. What do you think about that?

from dd-trace-java.

@realark yeah understood on not wanting to inadvertently continue unrelated things. I do think turning it on from servlet instrumentation automatically would be helpful. Thanks for clarifying on dd-trace-api; I'll give that a whirl in the meantime.

from dd-trace-java.