The flow for context propagation is as follows.
* <p>We inject into StreamRemoteCall constructor used for invoking remote tasks and performs a
* backwards compatible check to ensure if the other side is prepared to receive context propagation
* messages then if successful sends a context propagation message
*
* <p>Context propagation consist of a Serialized HashMap with all data set by usual context
* injection, which includes things like sampling priority, trace and parent id
*
* <p>As well as optional baggage items
*
* <p>On the other side of the communication a special Dispatcher is created when a message with
* DD_CONTEXT_CALL_ID is received.
*
* <p>If the server is not instrumented first call will gracefully fail just like any other unknown
* call. With small caveat that this first call needs to *not* have any parameters, since those will
* not be read from connection and instead will be interpreted as another remote instruction, but
* that instruction will essentially be garbage data and will cause the parsing loop to throw exception
* and shutdown the connection which we do not want
The problem was that on zulu8 loading OkHttp touches JFR which in turn
touches log manager - which would break things like JBOSS.
The fix is to delay installing agent (and writer) until log manager
things have settled down - in way similar to jmxfetch.
Unfortunately for 'main' agent this turns out to be more involved
because of classloader shenanigans.
Disabled by default, and only creates a span if existing trace detected.
To enable all of them:
* System Property: `-Ddd.integration.servlet.enabled=true`
* Environment Variable: `DD_INTEGRATION_SERVLET_ENABLED=true`
(They have independent configs as well. If needed, view the source below.)
For spring:
* Move more logic to the decorator.
* Use a fixed operation name, but set the resource name.
* Rename the root span instead of the parent span (If there are other spans in between this could make a difference.) Not sure what impact this would have if multiple controllers are called (ie, forward/include).
For Jax-rs:
* Rename the root span instead of the parent span (same concern as above with spring)
Attempt to reduce memory overhead requirements. Based on feedback, it seems 10k was overly agressive. In memory constrained environments, use soft values to ensure the cache isn’t pushing usage over the limit.
This is a more generic form of the previous `split-by-domain` and `split-by-instance`.
(Note: evaluation is done when a tag is set, so If multiple tags are configured, the last tag set will take precidence.)
For example, this setting can be used to rename `aws-sdk` spans to be identified with the corresponding `aws.service` tag:
```
-Ddd.trace.split-by-tags=aws.service
```
There are some slight differences with this setting compared with`dd.trace.http.client.split-by-domain` and `dd.trace.db.client.split-by-instance`. `split-by-tags` applies to every span, where `split-by-domain` and `split-by-instance` only apply to http and db client spans respectively.
The core changes are in Config and ServerDecorator.
Moved default tagging from Config::getRuntimeTags to Config::getLocalRootSpanTags. This changes the result of Config::getMergedJmxTags as well.
To preserve language for servers changed ServerDecorator::afterStart.
Other changes are in tests - the most complicated part is in TagsAssert::defaultTags. This now contains a bit too much conditional logic for my liking.
Otherwise it can interfere with the more common Servlet instrumentation (changing the root span name).
Unify attribute/property name for saving span on a request/context.
Also add tests for embedded GlassFish.
Laplie Anderson
Pawel Chojnacki
Laplie Anderson
Pawel Chojnacki
kfujita
Tyler Benson
Nikolay Martynov
Douglas Q Hawkins
dougqh
Trask Stalnaker