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 "Alex Parvulescu (JIRA)" <ji...@apache.org> on 2015/05/11 16:21:01 UTC

[jira] [Commented] (OAK-2861) TARMK Cold Standby better binary decoding

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

Alex Parvulescu commented on OAK-2861:
--------------------------------------

fixed in trunk with http://svn.apache.org/r1678758

> TARMK Cold Standby better binary decoding
> -----------------------------------------
>
>                 Key: OAK-2861
>                 URL: https://issues.apache.org/jira/browse/OAK-2861
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: segmentmk
>            Reporter: Alex Parvulescu
>            Assignee: Alex Parvulescu
>             Fix For: 1.3.0, 1.0.14, 1.2.3
>
>
> The ColdStandby relies on an inefficient decoding mechanism which increases exponentially the times needed to transfer a binary (ex. a 300mb file can go over 10min). The issue is around the use of a _ReplayingDecoder_ (the _ReplyDecoder_ class) which will eagerly create byte arrays of the original length for each received fragment of the transferred file. 
> So following the 300mb file example, for each inbound slice of hundreds of kbs, a new 300mb arrays is allocated, only to be thrown away by the _ReplayingDecoder_ once it figures out the entire stream is not available yet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)