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/12 09:53:59 UTC
[jira] [Comment Edited] (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 edited comment on OAK-2861 at 5/12/15 7:53 AM:
---------------------------------------------------------------
fixed in
* trunk with http://svn.apache.org/r1678758
* 1.2 branch http://svn.apache.org/r1678890
* 1.0 branch http://svn.apache.org/r1678682
was (Author: alex.parvulescu):
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)