Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Thu, 27 Feb 2014 14:55:19 +0000 (UTC)
From: "Jukka Zitting (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: <JIRA.12696852.1393225976874.118140.1393512919561@arcas>
In-Reply-To: <JIRA.12696852.1393225976874@arcas>
References: <JIRA.12696852.1393225976874@arcas>
Subject: [jira] [Commented] (JCR-3735) Efficient copying of binaries in
 Jackrabbit DataStores
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914611#comment-13914611 ] 

Jukka Zitting commented on JCR-3735:
------------------------------------

bq. So, what you suggest as the next step?

Given that the benefits of using {{FileChannel}} seem to be fairly limited and in some cases negative, I don't think this feature is worth the extra complexity. Thus I'd resolve this as Won't Fix and take another look at client code for options on avoiding the extra temporary file.


> Efficient copying of binaries in Jackrabbit DataStores
> ------------------------------------------------------
>
>                 Key: JCR-3735
>                 URL: https://issues.apache.org/jira/browse/JCR-3735
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core
>    Affects Versions: 2.7.4
>            Reporter: Amit Jain
>
> In the DataStore implementations an additional temporary file is created for every binary uploaded. This step is an additional overhead when the upload process itself creates a temporary file. 
> So, the solution proposed is to check if the input stream passed is a FileInputStream and then use the FileChannel object associated with the input stream to copy the file.


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)