You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Henry Saginor (JIRA)" <ji...@apache.org> on 2019/05/09 19:49:00 UTC

[jira] [Commented] (OAK-8275) Add NIO channel access to JCR binaries

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

Henry Saginor commented on OAK-8275:
------------------------------------

Hi [~reschke]

I think it's not possible to implement a wrapper just base on InputStream semantics that will work for binaries of all sizes because the initial marked position may get invalidated (see mark/reset JavaDoc contract for InputStream).

But I have attempted to implement 2 versions of SeekableByteChannel, one for oak blob and one for jcr binary, that work around mark/reset limitations by opening a new InputStream if reset fails. See [BlobByteChannel|https://github.com/hsaginor/jackrabbit-oak/blob/createChannel2/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/BlobByteChannel.java] and [BinaryByteChannel|https://github.com/hsaginor/jackrabbit-oak/blob/createChannel2/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/jcr/BinaryByteChannel.java] with respective unit tests [BlobByteChannelTest|https://github.com/hsaginor/jackrabbit-oak/blob/createChannel2/oak-store-spi/src/test/java/org/apache/jackrabbit/oak/plugins/value/BlobByteChannelTest.java] and [BinaryByteChannelTest|[https://github.com/hsaginor/jackrabbit-oak/blob/createChannel2/oak-store-spi/src/test/java/org/apache/jackrabbit/oak/plugins/value/jcr/BinaryByteChannelTest.java].]

 

> Add NIO channel access to JCR binaries
> --------------------------------------
>
>                 Key: OAK-8275
>                 URL: https://issues.apache.org/jira/browse/OAK-8275
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>            Reporter: Henry Saginor
>            Priority: Major
>
> This is a follow up to the discussion started in OAK-8186. Currently JCR binaries can only be accessed via InputStream. This is inefficient. It can also be inadequate for some use cases. For example handling some Zip file formats like deflate64 requires random access.
> The proposal is to add API that returns SeekableByteChannel
> Here is the new API I am proposing -
>  [https://github.com/hsaginor/jackrabbit/blob/createChannel/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/ChannelBinary.java]
>  [https://github.com/hsaginor/jackrabbit-oak/blob/createChannel2/oak-api/src/main/java/org/apache/jackrabbit/oak/api/Blob.java] (see 2 added methods)
> And all of the implementation changes -
>  [https://github.com/apache/jackrabbit-oak/compare/trunk...hsaginor:createChannel2]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)