Odd error after running a gatling-it:test using the SBT plugin

I’m seeing an error at the end of the test run, and I’m wondering what it means.

sbt gatling-it:test com.example.testApp.ProveItWorks
… // test runs

[info] Simulation ProveItWorks successful.
[info] Simulation(s) execution ended.
[success] Total time: 25 s, completed Sep 3, 2019, 10:11:42 AM
[error] Expected ID character
[error] Not a valid command: com
[error] Expected project ID
[error] Expected configuration
[error] Expected ‘:’
[error] Expected key
[error] Not a valid key: com (similar: compile, commands, scalaHome)
[error] com.example.testApp.ProveItWorks
[error] ^

Am I using it wrong? I couldn’t find anything on the current docs page for the plugin for how to run a particular simulation, so I’m just guessing on the syntax.

SBT version 1.2.8
Gatling SBT Plugin 3.0.0
Gatling 3.2.0

You’re confusing gatling:test and gatling:testOnly.

Found the answer. gatling-it:test runs everything, and does not expect a parameter. To run one, I needed to change :test to :testOnly. After making that change, it works fine.

This is what happens when one takes a 4-year break from using Gatling… :wink:

So now, all of a sudden, what used to be working is not working:

sbt gatling-it:testOnly com.example.testApp.ProveItWorks
[info] Loading settings for project gatling-sbt-seed-build from plugins.sbt …
[info] Loading project definition from /Users/jarrowwx/src/oss/gatling-sbt-seed/project
error: error while loading String, class file ‘/modules/java.base/java/lang/String.class’ is broken
(class java.lang.NullPointerException/null)
[info] Loading settings for project gatling-sbt-seed from build.sbt …
[info] Set current project to gatling-sbt-seed (in build file:/Users/jarrowwx/src/oss/gatling-sbt-seed/)
[info] Updating …
[info] Done updating.
[warn] There may be incompatibilities among your library dependencies; run ‘evicted’ to see detailed eviction warnings.
16:58:49.058 [INFO ] i.g.c.c.GatlingConfiguration$ - Gatling will try to use ‘gatling.conf’ as custom config file.
16:58:50.795 [INFO ] a.e.s.Slf4jLogger - Slf4jLogger started
16:58:53.483 [INFO ] i.g.h.e.HttpEngine - Start warm up
16:58:54.144 [INFO ] i.g.h.e.HttpEngine - Warm up done
Simulation com.example.testApp.MultipleFlows started…

Any idea why it is suddenly launching the wrong simulation?

You’ve upgraded to Java 12 and that causes a bug with sbt 1.2 which is supposed to be fixed in sbt 1.3.0 that was released today.

Pretty sure “all of a sudden” actually is “after I’ve upgraded to Java 12” :stuck_out_tongue:

It looks like I may have found the problem, and it may be a bug in either SBT or the plugin.

Launching from the command line fails:

sbt gatling-it:testOnly com.example.testApp.ProveItWorks

Launching from the sbt shell works


gatling-it:testOnly com.example.testApp.ProveItWorks

If it helps to debug the issue, my code is checked in here: https://github.com/JohnArrowwood/gatling-sbt-seed

In command line, you need quotes to group them so that sbt knows the class name is a param of the command.

BTW the following issue that contains the answer comes second in the Google search “gatling sbt testonly”.


Gatling doesn’t get along well with JDK 12 and also with the JRE that comes with it. I had all sorts of random stopping of script runs and other shenanigans like this until I downgraded my JDK to version 8 and JRE to version 9. If nothing works, my recommendation to you is to give this method a try.

Gatling only officially supports LTS releases, hence JDK 8 and 11.

I had faced many issues with Gatling regarding the JAVA (JDK & JRE) versions and after a lot of trial and error, I have settled on these versions - JDK 8 and JRE 9. So I would recommend these over JDK 11.

Nah. Using different JDK and JRE versions is nonsensical.
And I suspect the issues you had with JDK11 were actually an IntelliJ bug that was worked around in Gatling 3.2.1: https://github.com/gatling/gatling/issues/3787.

Probably that might be the case, but nevertheless - my setup (JDK 8 and JRE 9) works without an issue so far. I don’t wanna “disturb” it to test IntelliJ again with JDK & JRE11 [it takes a lot of time to re-configure!]. You know, if it works, it works!