Gatling test breaks Tomcat with IOException

Source code:

I am running some experiments with servlets and am using Gatling for load testing.

When I run my load test to upload a file that is about 500MB with more than 1 concurrent user using Gatling, most of the requests fail.

For example, for this load test:

import io.gatling.core.Predef._
import io.gatling.http.Predef._

class SyncUploadSimulation extends Simulation {

val httpConf = http.baseUrl("http://localhost:8080")

val scn = scenario("Upload files via sync endpoint")
.exec(http("Upload 1")


Tomcat fails with: org.apache.tomcat.util.http.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Unexpected EOF read on the socket
at org.apache.catalina.connector.Request.parseParts(
at org.apache.catalina.connector.Request.getParts(
at org.apache.catalina.connector.Request.getPart(
at org.apache.catalina.connector.RequestFacade.getPart(
at javax.servlet.http.HttpServletRequestWrapper.getPart(
at xyz.behrang.fileserver.sync.SyncUploadServlet.isPartValid(
at xyz.behrang.fileserver.sync.SyncUploadServlet.doPostImpl(
at xyz.behrang.fileserver.sync.SyncUploadServlet.doPost(
at javax.servlet.http.HttpServlet.service(
at javax.servlet.http.HttpServlet.service(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.tomcat.websocket.server.WsFilter.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at net.bull.javamelody.MonitoringFilter.doFilter(
at net.bull.javamelody.MonitoringFilter.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.StandardWrapperValve.invoke(
at org.apache.catalina.core.StandardContextValve.invoke(
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
at org.apache.catalina.core.StandardHostValve.invoke(
at org.apache.catalina.valves.ErrorReportValve.invoke(
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(
at org.apache.catalina.core.StandardEngineValve.invoke(
at org.apache.catalina.connector.CoyoteAdapter.service(
at org.apache.coyote.http11.Http11Processor.service(
at org.apache.coyote.AbstractProcessorLight.process(
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(
at java.base/java.util.concurrent.ThreadPoolExecutor$
at org.apache.tomcat.util.threads.TaskThread$
at java.base/
Caused by: org.apache.tomcat.util.http.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Unexpected EOF read on the socket
at org.apache.tomcat.util.http.fileupload.FileUploadBase.parseRequest(
at org.apache.catalina.connector.Request.parseParts(
... 35 more
Caused by: org.apache.catalina.connector.ClientAbortException: Unexpected EOF read on the socket
at org.apache.catalina.connector.InputBuffer.realReadBytes(
at org.apache.catalina.connector.InputBuffer.checkByteBufferEof(
at org.apache.tomcat.util.http.fileupload.MultipartStream$ItemInputStream.makeAvailable(
at org.apache.tomcat.util.http.fileupload.MultipartStream$
at java.base/
at org.apache.tomcat.util.http.fileupload.util.Streams.copy(
at org.apache.tomcat.util.http.fileupload.FileUploadBase.parseRequest(
... 36 more
Caused by: Unexpected EOF read on the socket
at org.apache.coyote.http11.Http11InputBuffer.fill(
at org.apache.coyote.http11.Http11InputBuffer.access$300(
at org.apache.coyote.http11.Http11InputBuffer$SocketInputBuffer.doRead(
at org.apache.coyote.http11.filters.IdentityInputFilter.doRead(
at org.apache.coyote.http11.Http11InputBuffer.doRead(
at org.apache.coyote.Request.doRead(
at org.apache.catalina.connector.InputBuffer.realReadBytes(
... 44 more

However a similar test using a framework other than Gatling, with 2 or even 100 concurrent requests, passes successfully without any issues:


set -eu

START=$(date +%s)
echo "Start time: ${START}."

for i in {1..100}
curl --silent --connect-timeout 3000 --max-time 3000 \
-F document=@"/path/to/500-mb-file.tar" \
localhost:8080/file-server/sync/upload &

END=$(date +%s)
echo "Start time: ${START}."
echo "End time : ${END}."
echo "Total time: ${END} - ${START} = $(expr ${END} - ${START})"
echo "Done."

Which outputs:

Start time: 1575208592.
Start time: 1575208592.
End time: 1575208688.
Total time: 1575208688 - 1575208592 = 96

Any ideas what is causing this?

I’ve attached TRACE level logs.

gatling.log (43.8 KB)

Works for me.
Are you sure you don’t hit a timeout?

Also, I’m very suspicious wrt your curl results. Uploading 500 MB on localhost in 96ms, really?

Just FYI I’m using AdoptOpenJDK 11 HotSpot.

And that’s 96 seconds.

Ah, so your problem is just the request timeout as default is 60s, see gatling.conf

Two simultaneous uploads takes less than 4-5 seconds.

Anyway, I increased the default timeout to an extremely large value and the problem persists:

Here is a simple Java program using Java 11’s build-in HTTP client that uploads the same file concurrently to the target servlet:

I tried it with up to 4 threads and it is working without any issues.

Unfortunately it is not well written so it consumes +500MB per thread so I couldn’t run it with many more threads but similar to curl, it doesn’t break Tomcat.

Have you tried removing javamelody?
I’ve had countless issues with it in the past, so I removed it before even testing on my side.

This is most likely a Gatling issue. It doesn’t happen when I make concurrent requests using another tool or using a small Java program.

Also this issue occurs only when size of the file to be uploaded is relatively large (~500MB). With a small file (60K) this error doesn’t occur.

I removed JavaMelody and it didn’t eliminate this issue.


Let me know if you want to SSH into my EC2 server. I will keep it around for another 24 hours.


I think I know what happens. Could you please share your file?

I’ve uploaded the file here:

It turns out there’s an issue with zero copy feature I was considering dropping anyway…
Until 3.4.0, please disable atling.http.ahc.enableZeroCopy in gatling.conf.

Thanks for reporting!

No worries. Disabling that fixed the problem.

Best regards,
Behrang Saeedzadeh