10000 Gatling 3.12.0 -> 3.13.1 results in java.lang.IllegalAccessException: module java.base does not open java.lang to unnamed module · Issue #4599 · gatling/gatling · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Gatling 3.12.0 -> 3.13.1 results in java.lang.IllegalAccessException: module java.base does not open java.lang to unnamed module #4599

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
sanderino666 opened this issue Nov 15, 2024 · 6 comments
Closed

Gatling 3.12.0 -> 3.13.1 results in java.lang.IllegalAccessException: module java.base does not open java.lang to unnamed module #4599

sanderino666 opened this issue Nov 15, 2024 · 6 comments
Labels
Type - Declined

Comments

@sanderino666
8000
Copy link

Upgrading our Gatling tests from 3.12.0 to 3.13.1 results in the following error:

13:51:59.150  [ERROR] i.g.a.Gatling$ - Run crashed
java.lang.IllegalAccessException: module java.base does not open java.lang to unnamed module @b9afc07
	at java.base/java.lang.invoke.MethodHandles.privateLookupIn(MethodHandles.java:287)
	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)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at io.gatling.plugin.util.ForkMain.runMain(ForkMain.java:67)
	at io.gatling.plugin.util.ForkMain.main(ForkMain.java:35)
java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at io.gatling.plugin.util.ForkMain.runMain(ForkMain.java:67)
	at io.gatling.plugin.util.ForkMain.main(ForkMain.java:35)
Caused by: java.lang.IllegalAccessException: module java.base does not open java.lang to unnamed module @b9afc07
	at java.base/java.lang.invoke.MethodHandles.privateLookupIn(MethodHandles.java:287)
	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)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	... 3 more

We are using Gatling in combination with the gatling-maven-plugin version 4.10.2.

As a workaround I tried to add the --add-opens flag but that results in the same error.

<plugin>
	<groupId>io.gatling</groupId>
	<artifactId>gatling-maven-plugin</artifactId>
	<configuration>
		<jvmArgs>--add-opens=java.base/java.lang=ALL-UNNAMED</jvmArgs>
		<runMultipleSimulations>true</runMultipleSimulations>
	</configuration>
</plugin>
@joloto
Copy link
joloto commented Nov 15, 2024 •
edited
Loading

We also see this problem after updating from 13.12.0 -> 13.13.1 - same stack trace posted above.
We use gatling-app packaged in a spring boot jar.

i.g.a.Gatling$            :86    - Run crashed
java.lang.IllegalAccessException: module java.base does not open java.lang to unnamed module @291ae
	at java.base/java.lang.invoke.MethodHandles.privateLookupIn(MethodHandles.java:287)
	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)

@slandelle
Copy link
Member

@sanderino666 sanderino666

We are using Gatling in combination with the gatling-maven-plugin version 4.10.2.

I don't think you are really using 4.10.2.
Or you're tweaking the JVM options in a way that removes the updated JVM options.
I've ran the official sample with no issue.

Please check your config and if you can't find an issue with it, provide a proper reproducer.

I'm closing for now. I'll reopen if you can provide a reproducer.

--add-opens=java.base/java.lang=ALL-UNNAMED

That's a wrong usage of maven list options.
It should be:

<jvmArgs>
  <jvmArg>--add-opens=java.base/java.lang=ALL-UNNAMED</jvmArg>
</jvmArgs>

But again, this is not supposed to be necessary when using gatling-maven-plugin version 4.10.2.

We use gatling-app packaged in a spring boot jar.

@joloto That's not a supported usage. We can't help with that. I recommend you stick to the official and documented usages.

@sanderino666
Copy link
Author
sanderino666 commented Nov 18, 2024 •
edited
Loading

@slandelle Thanks for your response!

I double checked, we are using 4.10.2 of the plugin but you were right, we are adding an additional JVM option.

So this works:

<configuration>
	<runMultipleSimulations>true</runMultipleSimulations>
</configuration>

And this works:

<configuration>
	<jvmArgs>
		<jvmArg>-Dmy.custom.arg=foo</jvmArg>
		<jvmArg>--add-opens=java.base/java.lang=ALL-UNNAMED</jvmArg>
	</jvmArgs>
	<runMultipleSimulations>true</runMultipleSimulations>
</configuration>

But this doesn't work anymore:

<configuration>
	<jvmArgs>
		<jvmArg>-Dmy.custom.arg=foo</jvmArg>
	</jvmArgs>
	<runMultipleSimulations>true</runMultipleSimulations>
</configuration>

It looks like although the javadoc of <jvmArgs> states "Extra JVM arguments to pass when running Gatling." it actually overrides all default options. Not sure if this is a regression in the gatling-maven-plugin or existing behavior we are seeing due to the --add-opens being introduced.

@slandelle
Copy link
Member

It's a javadoc issue, as the replacing vs overriding is controlled by the overrideJvmArgs option. Maybe we should change the default behavior.

@sanderino666
Copy link
Author

It feels a bit counter intuitive but this works:

<configuration>
	<overrideJvmArgs>true</overrideJvmArgs>
	<jvmArgs>
		<jvmArg>-Dmy.custom.arg=foo</jvmArg>
	</jvmArgs>
	<runMultipleSimulations>true</runMultipleSimulations>
</configuration>

And setting overrideJvmArgs to false:

<configuration>
	<overrideJvmArgs>false</overrideJvmArgs>
	<jvmArgs>
		<jvmArg>-Dmy.custom.arg=foo</jvmArg>
	</jvmArgs>
	<runMultipleSimulations>true</runMultipleSimulations>
</configuration>

Results is in the exception.

Might indeed be good to change the default behavior where the plugin controls the JVM options Gatling needs to run and the user (me in this case) can add additional JVM options. In case the user wants full control he can set overrideJvmArgs to true.

Could be helpful as well to add a not to the upgrade instructions so that users who are customizing the JVM options know how to proceed.

@slandelle
Copy link
Member

I've release gatling-maven-plugin 4.11.0, see gatling/gatling-maven-plugin@44129f2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Type - Declined
Milestone
No milestone
Development

No branches or pull requests
3 participants
@sanderino666 @slandelle @joloto
0