j.i.IOException: Premature close -Error

Hello All,
I have a script which is hitting a API POST call and submit a CSR,when i run the same request from the Postman it worked fine and get the expected response.When i tried the same call from the Gatling script with required parameters first instance it failed with Request Time out error, then i updated the value for pooledConnectionIdleTimeout = 1200000 and requestTimeout = 1200000 and ran the script then i ran the script and again it failed with error -j.i.IOException: Premature close .

i tried to investigate this issue with different options and as per the so many update from forums but no luck as of now.I have no clue how to move forward.

Any help will be helpful and it will unblock my blocker issue.


Hi @ksantosh1978,

Please, help us to help you!

  • What is working? (can you spare your postman configuration? did you try with curl?)
  • What did you try with gatling? Show us some code.



Hello sbrevet,
Thanks for the reply.
Please find the attached Postman Console log for the same call.

Please find the screenshot of the Gatling script block.
I have not tried with curl as of now.



I don’t get what is problem, only first request failed or all of them get timeout?
How it’s look like your http protocol configuration in Gatling?

@ksantosh1978 I’m sorry, but there’s really nothing we can do with screenshots. We’d need the actual Postman test and the ability to run it (is the API exposed on the internet?).

Thanks all for the update.I got the root cause of the issue and resolved it.

For future readers, @ksantosh1978 can you tell us what was the issue?


I start debugging the code with removing one by one header values in the request then when i removed the Content-Length parameter and ran the script it accepted the given payload and returned the expected response with 200 OK status…

It means that the body generate with ELFileBody is not as the fixed size.

Thank you for the explanation!


Don’t set the Content-Length header, let Gatling compute it for you!

@ksantosh1978 BTW, how did you end up with an explicit Content-Length header? The recorder is supposed to remove it. Did you manually force it?

I have not seted any Content-Length manually and left Gatling to decide dynamically.

I have not seted any Content-Length manually and left Gatling to decide dynamically.

Do you mean that this explicit Content-Length was generated by the Recorder?
If so, what’s your Gatling version? Did you use the proxy mode?

I have passed the Header map without Content-Length attribute in payload

val headers = Map(
  "accept" -> "application/json, text/plain, */*",
  "accept-encoding" -> "gzip, deflate, br",
  "accept-language" -> "en-US,en;q=0.9",
  "content-type" -> "application/json",
  "Origin" -> Constants.BASE_URL,
  "sec-ch-ua" -> """ Not A;Brand";v="99", "Chromium";v="101", "Google Chrome";v="101""",
  "sec-ch-ua-mobile" -> "?0",
  "sec-ch-ua-platform" -> "Windows",
  "sec-fetch-dest" -> "empty",
  "sec-fetch-mode" -> "cors",
  "sec-fetch-site" -> "same-origin",
  "user-agent" -> "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.67 Safari/537.36",
   "Cookie"->"cim_session= ${session_token}"

I think we don’t understand each other.
I’m trying to understand how the explicit .header("Content-Length", 3000) header displayed in your screenshot made it here. I’m trying to understand if it was generated by the Recorder, or if you’re the one who erroneously added it.

Sorry for confusion. I have not used the Gatling recorder for the scripts and everything written manually.
.header(“Content-Length”, 3000) initially i have added as per the Postman header requirements but later i removed as script was failing due to this and throwing the Timeout and Premature close error.

In the current script i have not added the .header(“Content-Length”, xxxxx) attribute.

OK, not a Gatling bug then. Thanks for confirming.

What happened was that, as you enforced the Content-Length manually, Gatling would not compute it in your stead.
As a result, the request had a Content-Length different from the actual body’s, causing the server to crash it on its side.

Thanks so much for the update and suport.