[jira] [Resolved] (SLING-6027) Support existing Chunked upload functionality in streaming mode.

["Ian Boston (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Boston resolved SLING-6027.
-------------------------------
    Resolution: Fixed

Fixed in r1759789
Test scripts can be found in bundles/servlets/post/developer-tests/testFileUploads.sh and uptodate documentation of the protocol with differences from the published protocol discovered in the code at bundles/servlets/post/Protocols.md

> 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)