Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
Servlets Post 2.3.12
-
None
Description
The non streaming uploads support a partial upload protocol implemented in request parameters that is known in Sling terms as "Chunked" upload and documented at https://cwiki.apache.org/confluence/display/SLING/Chunked+File+Upload+Support (not to be confused with Chunked Transfer encoding or the use of Http Range headers).
Sling Chunked uploading sends a sequence of POSTs containing multiple parts of a file upload. When all the parts are uploaded a final request is sent that causes all the parts to be merged into a single file in the JCR. From a streaming point of view, each part can be streamed with the streaming implementation supported by SLING-5948. Some additional code will be required to set the file name appropriately and the struture.
However, when the upload is completed, Sling must merge all the parts. To maintain the streaming nature of the upload, this must be achieved without incurring any local IO, otherwise the benefits of a streamed upload are lost.
I am not certain how to achieve the merge given the limitations of the JCR API other than by transferring all the body parts via the local JVM. That won't incur local Disk IO but will multiply the overall IO requirement by 3x.
If JCR/Oak had the functionality to concatenate Binaries it could do this more efficiently depending on the DS implementation. If JCR/Oak exposed an Seekable OutputStream the Application could avoid needing to save uploads to the JCR as individual files. If JCR/Oak allowed an update to a binary to start at a known location, again this could be avoided.