Gatling version: 3.13.1
Gatling flavor: java kotlin scala javascript typescript
Gatling build tool: maven gradle sbt bundle npm
I made sure I’ve update my Gatling version to the latest release
I read the and how to ask a question topics.
I provided a [SSCCE] (or at least, all information to help the community understand my topic)
I copied output I observe, and explain what I think should be.
Hi everyone,
I’m running Gatling in a standalone test jar with Java 17. I’m afraid this doesn’t seem fully officially supported, as the documentation suggests to run it with the Gatling Maven plugin, but please bear with me as I hope that this should be solvable.
For the main part running Gatling standalone works pretty well, I’m just running into the exception stated below when I don’t apply this workaround of opening the java.base class to ALL-UNNAMED with the following Java parameter:
--add-opens=java.base/java.lang=ALL-UNNAMED
The problem also does not happen when I disable the file Datawriter, e.g. when I only enable the console writer in the gatling.config, instead of console and file:
data {
writers = [console] #Removed file here
}
But unfortunately I need the file output.
I’m running Gatling with the following Java code:
Gatling.main(argArray);
where argArray contains the following parameters:
0 = "--simulation"
1 = "com.sw.performance.MyTest"
2 = "--results-folder"
3 = "gatling_results"
In Java Heap - Out of memory mostly by Netty framework the user MSlaski posted a related stack trace. There the solution was to upgrade the gatling-maven-plugin, but I’ve already upgraded it to the latest version (4.12.2) and it did not help.
I presume this is because I don’t use the gatling -maven-plugin at runtime, as I want to run the tests without having to install Maven.
Now I have the following two questions:
- Do you think this exception might be fixed in a future Gatling version?
- Until the issue is fixed, could I call Gatling differently? Maybe similarly on how the Maven plugin is running it?
Here’s the stack trace for my exception:
java.lang.IllegalAccessException: module java.base does not open java.lang to unnamed module @6293abcc
at java.base/java.lang.invoke.MethodHandles.privateLookupIn(MethodHandles.java:259)
at io.gatling.core.stats.writer.StringInternals.<clinit>(StringInternals.java:43)
at io.gatling.core.stats.writer.LogFileDataWriter.<init>(LogFileDataWriter.scala:221)
at io.gatling.core.stats.DataWritersStatsEngine$.$anonfun$apply$1(DataWritersStatsEngine.scala:51)
at scala.collection.immutable.List.map(List.scala:251)
at scala.collection.immutable.List.map(List.scala:79)
at io.gatling.core.stats.DataWritersStatsEngine$.apply(DataWritersStatsEngine.scala:46)
at io.gatling.app.Runner.newStatsEngine(Runner.scala:70)
at io.gatling.app.Runner.load(Runner.scala:88)
at io.gatling.app.Runner.run(Runner.scala:58)
at io.gatling.app.Gatling$.start(Gatling.scala:83)
at io.gatling.app.Gatling$.fromArgs(Gatling.scala:46)
at io.gatling.app.Gatling$.main(Gatling.scala:40)
at io.gatling.app.Gatling.main(Gatling.scala)
I think I’m really close to a solution without having to apply a workaround, but so far I couldn’t figure it out. I would be glad if you could help me there.
Edit: Mainly for future reference. I’ve been digging through the Gatling sources and found the same workaround applied in BuildSettings.scala (i.e. it also sets --add-opens=java.base/java.lang=ALL-UNNAMED). It was introduced with the same commit the StringInternals class was added. So, I guess it’s a known potential security vulnerability in Gatling as it weakens the encapsulation and security features of Java.