Does Quarkus stream files on the go when doing multipart fileupload or does it keep a copy of the file in memory before sending it upstream? - file-upload

Question

I need a help in understanding and getting clarity with regards to multipart file upload in Quarkus (v 2.11.3.Final)
In our project, we are using mutipart file upload and the request form looks like the following:
import org.jboss.resteasy.annotations.providers.multipart.PartType;
import javax.validation.Valid;
import javax.validation.constraints.NotNull;
import javax.ws.rs.FormParam;
import javax.ws.rs.core.MediaType;
import java.io.InputStream;
public class MultipartBody {
#NotNull(message = "DOCUMENT_METADATA_MISSING")
#FormParam("documentRequest")
#PartType(MediaType.APPLICATION_JSON)
#Valid
public DocumentForm document;
#NotNull(message = "DOCUMENT_CONTENT_MISSING")
#FormParam("content")
#PartType(MediaType.WILDCARD)
public InputStream file;
}
And then this stream is transferred to an upstream system using rest client like below
#Path("")
#RegisterRestClient
#Produces(MediaType.APPLICATION_JSON)
#RegisterProvider(LoggingFilter.class)
#ApplicationScoped
#Retry(maxDuration = 180000, delay = 100)
public interface IngestionClient {
#Consumes(MediaType.APPLICATION_OCTET_STREAM)
#Path("/upload/{batchId}/0")
#POST
UploadResponse uploadDocument(
#HeaderParam("X-File-Name") String documentName,
#HeaderParam("X-File-Type") String documentMimeType, #PathParam("batchId") String batchId,
InputStream content);
}
Following is the configuration done in the properties file
quarkus.http.limits.max-body-size=2048M
quarkus.http.body.preallocate-body-buffer=false
quarkus.http.body.merge-form-attributes=false
quarkus.http.body.handle-file-uploads=false
quarkus.http.limits.max-chunk-size=10M
In between the file is copied over to BufferedInputStream to detect the mime type before the transfer using the rest client is done. When I check the logs in debug mode, following is the sample observed.
2022-09-01 16:29:54,665 DEBUG [org.apa.htt.imp.con.PoolingHttpClientConnectionManager] (executor-thread-0) Connection request: [route: {}->http://127.0.0.2:8111][total available: 0; route allocated: 0 of 50; total allocated: 0 of 50]
2022-09-01 16:29:54,666 DEBUG [org.apa.htt.imp.con.PoolingHttpClientConnectionManager] (executor-thread-0) Connection leased: [id: 23][route: {}->http://127.0.0.2:8111][total available: 0; route allocated: 1 of 50; total allocated: 1 of 50]
2022-09-01 16:29:54,666 DEBUG [org.apa.htt.imp.exe.MainClientExec] (executor-thread-0) Opening connection {}->http://localhost:8080
2022-09-01 16:29:54,673 DEBUG [org.apa.htt.imp.con.DefaultHttpClientConnectionOperator] (executor-thread-0) Connecting to localhost/127.0.0.2:8111
2022-09-01 16:29:54,674 DEBUG [org.apa.htt.imp.con.DefaultHttpClientConnectionOperator] (executor-thread-0) Connection established
2022-09-01 16:29:54,674 DEBUG [org.apa.htt.imp.con.DefaultManagedHttpClientConnection] (executor-thread-0) http-outgoing-23: set socket timeout to 180000
2022-09-01 16:29:54,674 DEBUG [org.apa.htt.imp.exe.MainClientExec] (executor-thread-0) Executing request POST /upload/000000-00000/0 HTTP/1.1
2022-09-01 16:29:54,674 DEBUG [org.apa.htt.imp.exe.MainClientExec] (executor-thread-0) Target auth state: UNCHALLENGED
2022-09-01 16:29:54,674 DEBUG [org.apa.htt.imp.exe.MainClientExec] (executor-thread-0) Proxy auth state: UNCHALLENGED
2022-09-01 16:29:54,674 DEBUG [org.apa.htt.headers] (executor-thread-0) http-outgoing-23 >> POST /upload/000000--00000/0 HTTP/1.1
2022-09-01 16:29:54,674 DEBUG [org.apa.htt.headers] (executor-thread-0) http-outgoing-23 >> Accept: application/json
2022-09-01 16:29:54,674 DEBUG [org.apa.htt.headers] (executor-thread-0) http-outgoing-23 >> Content-Type: application/octet-stream
2022-09-01 16:29:54,675 DEBUG [org.apa.htt.headers] (executor-thread-0) http-outgoing-23 >> Content-Length: 44591990
2022-09-01 16:29:54,675 DEBUG [org.apa.htt.headers] (executor-thread-0) http-outgoing-23 >> Host: 127.0.0.2:8111
2022-09-01 16:29:54,675 DEBUG [org.apa.htt.headers] (executor-thread-0) http-outgoing-23 >> Connection: Keep-Alive
2022-09-01 16:29:54,676 DEBUG [org.apa.htt.headers] (executor-thread-0) http-outgoing-23 >> User-Agent: Apache-HttpClient/4.5.13 (Java/11.0.16)
2022-09-01 16:29:54,688 DEBUG [org.apa.htt.wire] (executor-thread-0) http-outgoing-23 >> "POST /upload/000000-00000/0 HTTP/1.1[\r][\n]"
2022-09-01 16:29:54,688 DEBUG [org.apa.htt.wire] (executor-thread-0) http-outgoing-23 >> "Accept: application/json[\r][\n]"
2022-09-01 16:29:54,688 DEBUG [org.apa.htt.wire] (executor-thread-0) http-outgoing-23 >> "Content-Type: application/octet-stream[\r][\n]"
2022-09-01 16:29:54,689 DEBUG [org.apa.htt.wire] (executor-thread-0) http-outgoing-23 >> "Content-Length: 44591990[\r][\n]"
2022-09-01 16:29:54,689 DEBUG [org.apa.htt.wire] (executor-thread-0) http-outgoing-23 >> "Host: 127.0.0.2:8111[\r][\n]"
2022-09-01 16:29:54,689 DEBUG [org.apa.htt.wire] (executor-thread-0) http-outgoing-23 >> "Connection: Keep-Alive[\r][\n]"
2022-09-01 16:29:54,689 DEBUG [org.apa.htt.wire] (executor-thread-0) http-outgoing-23 >> "User-Agent: Apache-HttpClient/4.5.13 (Java/11.0.16)[\r][\n]"
2022-09-01 16:29:54,690 DEBUG [org.apa.htt.wire] (executor-thread-0) http-outgoing-23 >> "[\r][\n]"
2022-09-01 16:29:54,690 DEBUG [org.apa.htt.wire] (executor-thread-0) http-outgoing-23 >> "%PDF-1.7[\n]"
2022-09-01 16:29:54,690 DEBUG [org.apa.htt.wire] (executor-thread-0) http-outgoing-23 >> "%[0xe2][0xe3][0xcf][0xd3][\n]"
2022-09-01 16:29:54,690 DEBUG [org.apa.htt.wire] (executor-thread-0) http-outgoing-23 >> "2 0 obj[\n]"
2022-09-01 16:29:54,690 DEBUG [org.apa.htt.wire] (executor-thread-0) http-outgoing-23 >> "<</Length 99110/Filter/FlateDecode>>[\n]"
2022-09-01 16:29:54,691 DEBUG [org.apa.htt.wire] (executor-thread-0) http-outgoing-23 >> "stream[\n]"
The interesting part in the request being sent is the content-length. Now my question is that if Quarkus does not store the file locally based on the above configuration then how is it able to measure the content length upfront before starting the upload to upstream.
One additional aspect of the test performed is that this was tried using postman where the content length is automatically calculated at the time of performing the upload and the file size was 40MB approx. Any direction with regards to this question will help. Do I need to implement something differently?
The reason for asking the question is that we have a gateway behind which the application resides and this gateway has a limitation on the time within which the application has to respond back otherwise the connection is closed. So far the assumption was that the file is being streamed but on doing this investigation my curiosity arose...