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

sbt

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

If it helps to debug the issue, my code is checked in here: GitHub - JohnArrowwood/gatling-sbt-seed: Gatling starter project, with all my favorite helper classes

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”.

https://github.com/gatling/gatling/issues/3360#issuecomment-335105340

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!