Replacing Advice.class references with string construction.
This stops the JVM from loading the Advice classes which are used as templates for byte buddy and doesn't ever need to be run directly.
This eliminates ~130 class loads at start-up -- and saves 0.5MiB in metaspace
(Don’t be surprised when things break with 2.8… They’re religious about removing deprecated methods on minor release versions. If they followed standard convention, they’d likely be on at least 11.x.)
Add client test for 2.4-2.5 http library. 2.6+ won’t work because the underlying frameworks we instrument are shaded.
Also add server tests. We could do a lot more testing since it seems play still supports using Netty as the backing server even though it’s not the default. It’s difficult to do extensive testing though because they have so many breaking changes between versions.
Currently missing the authentication tests which need to be added to the parent, but other than that, testing is more thorough.
Discovered that trace propagation for Jetty Async is currently busted so I commented that portion of the test out until we can get it fixed.
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.
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).
Previously we were inheriting from the parent and also often setting as a tag.
Apply default span assertion to verify the spanType is being checked properly. (Include error state too.)