hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-15477) Do not save 'next block header' when we cache hfileblocks
Date Mon, 25 Apr 2016 23:36:13 GMT

     [ https://issues.apache.org/jira/browse/HBASE-15477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

stack updated HBASE-15477:
    Attachment: 15477.backport.branch-1.v5.patch

Copied a buffer to itself in HFileBlock rather than to newly allocated ByteBuffer.

Hopefully this fixes the interesting split issue, one that fails faithfully up on apache boxes
but never locally.

> Do not save 'next block header' when we cache hfileblocks
> ---------------------------------------------------------
>                 Key: HBASE-15477
>                 URL: https://issues.apache.org/jira/browse/HBASE-15477
>             Project: HBase
>          Issue Type: Sub-task
>          Components: BlockCache, Performance
>            Reporter: stack
>            Assignee: stack
>             Fix For: 2.0.0
>         Attachments: 15366v4.patch, 15477.backport.branch-1.patch, 15477.backport.branch-1.v2.patch,
15477.backport.branch-1.v3.patch, 15477.backport.branch-1.v4.patch, 15477.backport.branch-1.v4.patch,
15477.backport.branch-1.v5.patch, 15477.patch, 15477v2.patch, 15477v3.patch, 15477v3.patch,
>     When we read from HDFS, we overread to pick up the next blocks header.
>     Doing this saves a seek as we move through the hfile; we save having to
>     do an explicit seek just to read the block header every time we need to
>     read the body.  We used to read in the next header as part of the
>     current blocks buffer. This buffer was then what got persisted to
>     blockcache; so we were over-persisting wrtiting out our block plus the
>     next blocks' header (overpersisting 33 bytes). Parse of HFileBlock
>     complicated by this extra tail. Fix.

This message was sent by Atlassian JIRA

View raw message