[ https://issues.apache.org/jira/browse/SLING-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SLING-6027: ------------------------------ Fix Version/s: Servlets Post 2.3.14 > 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 > Assignee: Ian Boston > Fix For: Servlets Post 2.3.14 > > > 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)