[ https://issues.apache.org/jira/browse/HBASE-7336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13529712#comment-13529712 ]
stack commented on HBASE-7336: ------------------------------ bq. tryLock without a timeout returns immediately. Sorry. Thought for some reason it waited. bq. How many, though? And I am not sure how this would interact with the block cache (would probably be OK). One per scanner? Can we look at a scanner and figure somehow if its long or short? If start/stop row? Limit? Maybe allow someone pass a hint? Compactions should go get their own Reader? > HFileBlock.readAtOffset does not work well with multiple threads > ---------------------------------------------------------------- > > Key: HBASE-7336 > URL: https://issues.apache.org/jira/browse/HBASE-7336 > Project: HBase > Issue Type: Bug > Reporter: Lars Hofhansl > Assignee: Lars Hofhansl > Priority: Critical > Fix For: 0.96.0, 0.94.4 > > Attachments: 7336-0.94.txt, 7336-0.96.txt > > > HBase grinds to a halt when many threads scan along the same set of blocks > and neither read short circuit is nor block caching is enabled for the dfs > client ... disabling the block cache makes sense on very large scans. > It turns out that synchronizing in istream in HFileBlock.readAtOffset is the > culprit. -- 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