Also move jdbc classes to bootstrap to reduce size and complexity of those reference checkers.
These changes reduce the total file size of these instrumentation classes by 635k, which should also result in decent memory savings.
- Cache response per connection to ensure as little communication overhead as possible is needed
- change context payload serialization to use plain hashmap
+ add more logging
- only set parent context on root entry point
+ use decorator to create spans
- Use Instrumentation context to avoid reflection
- separate integration parts into packages
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
Tyler Benson
Laplie Anderson
Pawel Chojnacki