I've been running the gatling performance tests and have noticed that one of our APIs is throwing the following error at the HttpProtocolBuilder
stage:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:64)
Caused by: java.lang.NoSuchFieldError: DNT
at io.gatling.http.HeaderNames$.<clinit>(Headers.scala:44)
at io.gatling.http.HttpDsl.$init$(HttpDsl.scala:52)
at io.gatling.http.Predef$.<clinit>(Predef.scala:19)
I suspect this is due to a mismatch in dependency versions and sure enough I noticed that the working APIs are using this netty version
[INFO] | | - io.gatling:gatling-http:jar:3.7.6:test
[INFO] | | | \- io.gatling:gatling-http-client:jar:3.7.6:test
[INFO] | | | - io.netty:netty-handler-proxy:jar:4.1.65.Final:test
[INFO] | | | | \- io.netty:netty-codec-socks:jar:4.1.65.Final:test
[INFO] | | | - io.netty:netty-resolver-dns:jar:4.1.65.Final:test
[INFO] | | | | \- io.netty:netty-codec-dns:jar:4.1.65.Final:test
[INFO] | | | - io.netty:netty-codec-http2:jar:4.1.65.Final:test
[INFO] | | | - io.netty:netty-tcnative-boringssl-static:jar:2.0.39.Final:test
Whereas the failing one is using
[INFO] | | - io.gatling:gatling-http:jar:3.7.6:test
[INFO] | | | \- io.gatling:gatling-http-client:jar:3.7.6:test
[INFO] | | | - io.netty:netty-handler-proxy:jar:4.1.31.Final:test
[INFO] | | | | \- io.netty:netty-codec-socks:jar:4.1.31.Final:test
[INFO] | | | - io.netty:netty-resolver-dns:jar:4.1.31.Final:test
[INFO] | | | | \- io.netty:netty-codec-dns:jar:4.1.31.Final:test
[INFO] | | | - io.netty:netty-codec-http2:jar:4.1.31.Final:test
[INFO] | | | - io.netty:netty-tcnative-boringssl-static:jar:2.0.20.Final:test
Does anyone know why the APIs might be using different netty versions when they come from the exact same gatling library? And how to potentially fix it?
Can't share much more information due to it being a work project.
Cheers, Kris
CodePudding user response:
Does anyone know why the APIs might be using different netty versions when they come from the exact same gatling library?
No idea what you mean here.
My2cents: Gatling is not the only library in your project pulling netty. Some other library, or some dependencyManagement block, force a downgrade to a very old version (4.1.31 was released 4 years ago).
Don't downgrade, upgrade instead. If you have a library that pulls a dependency from 4 years ago, there's a very good chance it's super old too.