Previously the scope was the http client span, which could result in deep nesting. Now it is the parent span.
Before
[——————Parent—————]
[ ^ ———Client—————]
[ ^—Child—]
Now:
[——————Parent—————]
[ ^ —Client—] [ ^—Child—]
Also improve the tests.
Alpha version of Jetty 10 was released and it seems to be compiled for
java versions above 8 so tests fail on java8.
Limit latest dep Jetty tests to Jetty 9 for now.
Alpha version of Jetty 10 was released and it seems to be compiled for
java versions above 8 so tests fail on java8.
Limit latest dep Jetty tests to Jetty 9 for now.
By definition, a Flow generated by a SuperPool does not respect ordering
of requests and responses, and in fact will typically only rarely actually
behave in the fashion that the instrumentation expects. The previous implementation
would start a span for a given request before submitting it as input to the flow,
and close the span with whatever response is next emitted by the flow. This
request will rarely (if ever) be the actual response for the request that
started the span. For more info, see the official docs at
https://doc.akka.io/docs/akka-http/current/client-side/host-level.html#configuring-a-host-connection-pool
Additionally, compiling this instumentation against scala 2.11, and only
scala 2.11 can (and does) cause significant problems at runtime due to the
fact that Scala is explicitly not binary compatible across major versions.
Remove compiled Scala artifacts from the actual instrumentation. Scala
is not binary compatible across major versions, and having
AkkaHttpClientTransformFlow.scala be in the artifact causes problems
when using anything but Scala 2.11.
Having the AkkaHttpClientTransformFlow implementation be in pure java
utilizing the Akka-stream Java DSL ensures that this will work across
any given Scala major version.
Tyler Benson
Nikolay Martynov
Laplie Anderson
Luca Abbati
Laplie Anderson
David Pratt