[
https://issues.apache.org/jira/browse/SLING-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15470863#comment-15470863
]
Ian Boston commented on SLING-6027:
-----------------------------------
Nothing can be done to eliminate the IO from copying chunks into the final
result other than using streams directly wrapped into a containing stream.
Discussion on potential improvements to Oak are being discussed on oak-dev at
http://markmail.org/thread/lnzkwhcsqhvxzj2p.
Implementing both approaches in
https://github.com/ieb/sling/compare/trunk...ieb:SLING-6027
> 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)
