The issue we are trying to fix here seems to be a result of two concurrent issues.
Cassandra driver's used by atlas 1.1.0 brings in a old version of netty < 4.0.23.
In version 4.0.25 netty raised exception in `UniqueName` class for duplicate name
```
if (map.putIfAbsent(name, Boolean.TRUE) != null) {
throw new IllegalArgumentException(String.format("'%s' is already in use", name));
}
```
This changed in 4.0.26 where exception was not thrown, instead the duplicate key was just ignored.
```
protected UniqueName(String name) {
this.name = checkNotNull(name, "name");
id = nextId.incrementAndGet();
}
```
Now this alone would not be enough. The only way I was able to reproduce is if two different class loaders tries to load the
same class `AttributeKeys` twice.
I tried to look into Atlas source code (which is huge) and I could not find a clear path of how this would be possible.
Further more, looking at some build scripts that a user experiencing this issue provided,
it looks like they are doing everything correctly and there is nothing they should change.
In conclusion, I believe that even if this is not a very clean approach,
we should be resilient to this use case, when a customer using netty <4.0.25 in an
older version of Apache Atlas (or with some sort of class loader behavior).
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.
Luca Abbati
Nikolay Martynov
Tyler Benson
David Pratt
Laplie Anderson