[
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
