How to Troubleshoot IO.Exception: Premature Close?

Gatling (Open-Source)
1

Hi,

In sequence:

  1. Upgrade to latest Gatling 3.2.0 (which you should have done prior to reporting anyway) so you can check if this was a (Netty?) issue that has been fixed since then

  2. Disable OpenSSL in gatling.conf (set gatling.http.ahc.useOpenSsl to false)

  3. Investigate yourself: use Wireshark and try to spot the difference between what you have with Apache HttpClient and Gatling

  4. Consider contracting with us so we can investigate in your environment
    Regards,

2
  1. Sorry that I didn’t do that before. Did it now, didn’t change the behavior.
  2. Good idea, didn’t help.
  3. I’ll try this. My employer thinks it’s a good idea to deny developers admin privileges, which I would need to install pcap for wireshark. But I’ll try to find a way to analyze the traffic.
  4. That would be great, but I doubt I’d be able to convince the necessary people, at least for now. The company has an official testing tool and our team is just evaluating whether a more lightweight tool like gatling would be better for us. Paying external resources is quite difficult in this situation.
3

I do have a question: are the request headers we see in the logs correct:
content-type: application/x-www-form-urlencoded
content-length: 134

  • Header names are case insensitive. Is there any chance your server is not properly implemented and handle them in a case sensitive fashion?
  • Do you really post a form? Or is body content actually JSON, in which case content-type should be application/json.
  • Is content-length generated by Gatling or manually set? Is the value correct? If it’s not and actually body is smaller, the server is going to wait for bytes that will never be sent.
4

The server seems to handle Headers case insensitive. I tried curl with different cases for the headers and all worked.

`

curl -k -v https://tokenmanager-dev.intranet.mycompany.com/auth/realms/internal/protocol/openid-connect/token \

-H “content-type: application/x-www-form-urlencoded” \

-H “content-length: 134” \

-d “grant_type=password&client_id=someId&client_secret=theSecret&username=usr”

`

I do really post a form, that is not unusual to get a token for OAuth 2.0.

content-length is generated by Gatling:

val scn = scenario("myScenario") .exec( http("Request Token") .post(tokenmanagerUrl + "/auth/realms/internal/protocol/openid-connect/token") .header("Content-Type", "application/x-www-form-urlencoded") .body(StringBody("grant_type=password&client_id=" + oauthClientId + "&client_secret=" + oauthSecret + "&username=" + username)) .check(status.is(200)) .check(jsonPath("$.access_token").saveAs("access_token")) ).exitHereIfFailed

5

Are you sure you don’t have characters that should be url-encoded?
It’s pretty weird and dangerous to craft x-www-form-urlencoded bodies manually, all the more as Gatling has formParam.

If that’s still not the issue, we from GatlingCorp can’t do more without a contract, sorry.

6

I solved it, it actually was an SSL issue. On a colleagues pc with an older gatling version the error message was more helpful. I don’t know if it was just a different message or really a different issue, but it lead me to the idea, that gatling ignores the truststore settings in conf/gatling.conf

With useOpenSsl = false in the config and -Djavax.net.ssl.trustStore=C:/certs/truststore.jks -Djavax.net.ssl.trustStorePassword=pwd in bin/gatling.bat or as part of %JAVA_OPTS% it worked.

Thanks for the help!

7

Good catch, there was indeed a bug when disabling OpenSSL where we didn’t honor TrustStore from gatling.conf (nor use trusty TrustManager).
This is fixed now, see https://github.com/gatling/gatling/issues/3785

Now, this doesn’t explain why things didn’t work with OpenSSL, all the more if the issue was with the TrustStore as:

  • the one configured in gatling.conf was properly honored when using OpenSSL (the issue was only when disabling it)
  • if you don’t force a TrustManager in gatling.conf, by default, we use a trusty TrustManagerFactory that accepts any certificate (Gatling is a load testing tool and lots of people have QA environments with private or self signed certs and expect Gatling to work out of the box).
    By any chance, have you disabled useInsecureTrustManager in gatling.conf?

Regards,