Pulls out utility classes for reuse by other projects.
This also meant the dependency had to be bundled with dd-trace-ot since it isn't published as a separate dependency.
Reduced the size of dd-java-agent jar by about 2 MB. Jackson is not removed completely though as it is still a dependency of jmxfetch.
Trace serialization is primarily done directly with msgpack.
Response deserialization and LoggingWriter serialization is done with mochi.
Msgpack Serialization buffer still not being reused though.
First disruptor (TraceProcessingDisruptor) does processing, which is currently limited to serialization, but in the future can do other processing such as TraceInterceptor invocation.
Second disruptor (BatchWritingDisruptor) takes serialized traces and batches them into groups and flushes them periodically based on size and time.
When limit is exceeded, a NoopScope is returned.
Allow custom ScopeManager to be provided, with the plan to remove `ScopeContext` customization in the future.
Pior to this change, DDSpanBuilder.withTag behaves different than DDSpan.setTag when decorators are triggered.
Specifically builder.withTag(a, val).withTag(b, val) can behave differently than span.setTag(a, val); span.setTag(b, val)
This change makes a small step towards determinism by changing the HashMap inside DDSpanBuilder into a LinkedHashMap. That guarantees the tags from withTags translated to the same sequence of setTag calls.
NOTE: Even with this change, there are inconsistencies when tags are removed or set to an empty value.
Tested on docker. Although "/proc/self/cgroup" file is not empty, "/proc/self/cgroup".toFile().length() returns 0
as does Files.size("/proc/self/cgroup").
Improving the reliability of the slow sender test.
Still needs work, but to make this truly reliable, I'd need to add to the DDAgentWriter API. I'll probably do that, but I'm trying to start with sticking to the existing API.
To prevent unbounded memory consumption, restricting the size of the sender queue. Also, lowering the size of the Disruptor queue.
Unfortunately, our choice of a ScheduledExecutorService makes this a bit difficult, since ScheduledExecutorService doesn't allow us to supply the queue.
A bigger change is in-order but for now, this change restricts the queue size by introducing a Semaphore around the ScheduledExecutorService.
In effort to making testing easier, I introduced Monitor.onFlush. This is used in the new slow response test which attempts to simulate a situation where the sending queue would back up.