java.lang.NoClassDefFoundError: io/netty/channel/IoHandle

Gatling (Open-Source)
1

Gatling version: 3.14.0
Gatling flavor: java kotlin scala javascript typescript
Gatling build tool: maven gradle sbt bundle npm

After upgrading to Gatling from 3.13.5 to 3.14.0
I am getting the following error:

Caused by: java.lang.NoClassDefFoundError: io/netty/channel/IoHandle
        at io.gatling.netty.util.Transports.<clinit>(Transports.java:60)

I am using Spring Boot parent 3.4.5 with Netty 4.1.119.Final
According to Gatling upgrade from 3.13 to 3.14 I did not expect any troubles.

Declared Maven dependency

<dependency>
    <groupId>io.gatling.highcharts</groupId>
    <artifactId>gatling-charts-highcharts</artifactId>
</dependency>

Downgrading for now, but I would appreciate more descriptive release notes.

I made sure I’ve update my Gatling version to the latest release
I read the guidelines 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.

2

I am using Spring Boot parent 3.4.5 with Netty 4.1.119.Final
According to Gatling upgrade from 3.13 to 3.14 I did not expect any troubles.

We only document upgrade steps that we have control over.
Here, your issue is that you are mixing Gatling’s dependencies with Spring Boots and are downgrading from Netty 4.2 to Netty 4.1. Such compatibility issue could happen with any dependency.

You have 2 solutions:

  • stop mixing Spring Boot and Gatling. In particular, there’s rarely any reason to have Gatling tests depend on your application sources, it particular its web framework.
  • Upgrade to Netty 4.2 that Gatling 3.14 requires
3

Ok, it is a good idea to keep the Gatling tests in a separate module without Spring Boot. Anyway, I still believe that the release notes could be better. See Spring Boot release notes, especially the section “Dependency Upgrades” Release v3.4.5 · spring-projects/spring-boot · GitHub

4

Spring Boot is a web application framework. By definition, it’s intended to have a humongous dependency tree and have to deal with users bring their own libraries.
Gatling is a load test software. Users might bring in some libraries for some specific needs but it’s their responsibility. Mixing with the application’s classpath or worse, test classpath, and end up shipping Spring, Hibernate, JUnit, Selenium, etc, is simply a bad practice.