[
https://issues.apache.org/jira/browse/HBASE-13036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14324700#comment-14324700
]
Devaraj Das commented on HBASE-13036:
-------------------------------------
[~apurtell], this issue doesn't affect 0.98. It only affects branch-1+. In
those branches, the scans uses the table's thread-pool for executing the scans.
Also, in those branches, the meta lookup can happen on replicas of the meta (if
the appropriate configs are enabled). In a replicated-meta setup, the number
'5' is assumed as the max number of replicas by default (unless it is
configured to be of a higher value). In a non-replicated-meta setup, only one
thread would be active.
> Meta scanner should use its own threadpool
> ------------------------------------------
>
> Key: HBASE-13036
> URL: https://issues.apache.org/jira/browse/HBASE-13036
> Project: HBase
> Issue Type: Bug
> Reporter: Devaraj Das
> Assignee: Devaraj Das
> Attachments: 13036-1.txt
>
>
> Currently, during region location lookups, the meta is scanned and for this
> the scanner submits a request to the thread pool of the table in question.
> Sometimes, it might happen that many scan requests are simultaneously
> submitted on the table - let's say 256, and this is the max size of the
> thread pool. Each of these scan requests would in turn submit meta scan
> requests on the same thread pool, but they will be in the queue. The meta
> scans will not happen and the original table scans would lock up. The meta
> scans should use a different thread pool.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
