hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manukranth Kolloju (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-8330) What is the necessity of having a private ThreadLocal in FSReaderV2
Date Fri, 12 Apr 2013 23:20:15 GMT

    [ https://issues.apache.org/jira/browse/HBASE-8330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630747#comment-13630747

Manukranth Kolloju commented on HBASE-8330:

Sure, I will post it on the mailing list.
> What is the necessity of having a private ThreadLocal in FSReaderV2
> -------------------------------------------------------------------
>                 Key: HBASE-8330
>                 URL: https://issues.apache.org/jira/browse/HBASE-8330
>             Project: HBase
>          Issue Type: Brainstorming
>          Components: HFile
>    Affects Versions: 0.89-fb
>            Reporter: Manukranth Kolloju
>            Assignee: Manukranth Kolloju
>            Priority: Minor
>             Fix For: 0.89-fb
> I was trying to investigate the scenarios in which we perform a seek back of 24 bytes(Header
size) while we do a HFileBlock read. In the process I stumbled upon this issue. In order to
avoid the seek back problem, what we do is to store the header of the next block in a class
named PrefetchedHeader. This prefetched header is stored as a private ThreadLocal object in
the FSReaderV2 class. I was wondering why we would be needing a ThreadLocalc when each FSReader
object has its own PrefetchedHeader object and moreover if its private. Can anybody familiar
with this part of the code tell me what was the design decision that was taken at that time?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message