You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Manukranth Kolloju (JIRA)" <ji...@apache.org> on 2013/04/12 08:19:15 UTC

[jira] [Created] (HBASE-8330) What is the necessity of having a private ThreadLocal in FSReaderV2

Manukranth Kolloju created HBASE-8330:
-----------------------------------------

             Summary: 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