Ian Boston created SLING-6027:
---------------------------------
Summary: Support existing Chunked upload functionality in
streaming mode.
Key: SLING-6027
URL: https://issues.apache.org/jira/browse/SLING-6027
Project: Sling
Issue Type: Bug
Components: Servlets
Affects Versions: Servlets Post 2.3.12
Reporter: Ian Boston
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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
