SSLExceptions when using Coursier, 401 when using Ivy

I’ve inherited a Gatling project intended to load test a Rest API that I’m told has worked in the past, but on initial build, all requests were getting KO responses with the exception j.n.s.SSLException: failure when writing TLS control frames

I tried a couple of more simple requests from the quickstart & resources pages (a & b below), and those also get the same exception response.

a:

.exec(http("GatlingExample")
  .get("http://computer-database.gatling.io"))

b:

.exec(http("Gatling https issue example")
  .get("https://www.github.com/gatling/gatling/issues")
  .resources(
    http("api.js").get("https://collector-cdn.github.com/assets/api.js"),
    http("ga.js").get("https://ssl.google-analytics.com/ga.js")
  ))

The only changes I’d made were to update the versions of the Gatling dependencies in the build.sbt (from 3.2.1 to 3.3.1), so I tried reverting that change, and started getting wrong checksum errors on build. Having found a discussion of checksums, I’ve changed build.sbt to use Ivy instead (as below), and am now getting 401 Unauthorised for all of my requests.

build.sbt disabling Coursier:

useCoursier := false
update / checksums := Nil

The 401 errors I believe will need resolving with the assistance of the API developers, but if anyone could please share any thoughts on whether/how I could better have addressed the SSLExceptions, I’d be keen to learn.

Looks like network issues on your side.
The public facing urls you provided just work fine for me.

Thanks Stéphane: I’m happy that the 401s are something I need to work out (perhaps I shouldn’t have mentioned them), it’s more the wrong checksum that felt like something I need to resolve. But perhaps that’s an SBT issue rather than a Gatling issue? Have put together the suggested SSCCE project, and will look for an appropriate SBT forum to ask the question.

There’s absolutely no way your problem is related to sbt.

Appreciate your confidence: difficult for me to know when this is very new. It’s the fact that changing the dependency management gives different SSL behaviour that led me to consider SBT as something I needed to better understand. If the build.sbt file within the SSCCE project contains the two lines to disable Coursier, I get 100% success. If I introduce the two lines, I start getting the failure when writing TLS control frames again. That’s where you were suggesting network issues, so I’m hoping to capture the request & response with Fiddler & see if it tells me anything.

Your reproducer doesn’t even compile:

[error] /Users/slandelle/Downloads/SSCCE/src/test/scala/UserSimulation.scala:4:18: illegal cyclic reference involving class Simulation
[error] class Simulation extends Simulation {
[error] ^

After:

  • renaming class to UserSimulation (matching file name)
  • upgrading sbt to 1.3.13
  • removing duplicate "scalaVersion := “2.13.1” which is wrong as Gatling 3.3.1 requires Scala 2.12
  • removing “netty-all” that causes multiple possibly incompatible versions of the same classes as Gatling pulls the individual modules with the proper expected version

Stéphane,

That’s above & beyond: thank you so much for providing that level of input & attention. I don’t know how I managed to zip up the project in that state, but clearly I’ve failed to be as systematic as I intended. I’ve downloaded the project again, applied your suggestions, and then reintroduced the requests that were giving me issues , and am now getting a mix of responses that’s much more useful.

Very much appreciated: please feel free to point me at a charity of your choice as a way of expressing my appreciation.

Glad it helped :slight_smile:

Contributing to a charity would be great, feel free to pick one you like, there are sadly so many causes that need help.

And if at some point, your organization feels the need to go beyond Gatling OSS, feel free to give FrontLine a try, that’s how we make a living :slight_smile:

Cheers,