[
https://issues.apache.org/jira/browse/SLING-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455187#comment-15455187
]
Ian Boston commented on SLING-6027:
-----------------------------------
To aggregate a stream create a wrapped InputStream that reads from each chunk
in turn as the commit is processed. If the DS is an S3 DS (for example) this
wont incur any local Disk IO, assuming the S3 DS doesn't incur local Disk IO.
If the DS is a remove FS DS all the IO may be served via the OS Disk cache.
Over a direct streamed upload there is 1 read per body part + 1 write for the
final file in addition to the streaming for all the body parts.
> 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)
