hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2405) Close, split, open of regions in RegionServer are run by a single thread only.
Date Fri, 02 Apr 2010 21:39:27 GMT

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

stack commented on HBASE-2405:

@Andrew I like two queues idea; liveness queue and background-task queue. We'd have multiple
threads servicing the liveness queue but perhaps the single worker doing the compactions and
splits queue.

@Jon Yes, all should go via compactsplitthread.  Lets fix that and make even manual requests
for compactions go this route.  Understood about the worry introducing more parallellism but
ain't sure how else to do it if you don't want to "block the thread processing the message"
(even if we redo close so we dbl-flush, it'll still take the same amount of elapsed time to
close, it'll just be taking writes longer before it puts up the close flag).  And good point
that close, open, etc., will come in via callbacks though I envisioned the callback would
just add to the aforementioned queues and then return -- not wait on close/open to complete.

> Close, split, open of regions in RegionServer are run by a single thread only.
> ------------------------------------------------------------------------------
>                 Key: HBASE-2405
>                 URL: https://issues.apache.org/jira/browse/HBASE-2405
>             Project: Hadoop HBase
>          Issue Type: Bug
>            Reporter: stack
>             Fix For: 0.20.4, 0.21.0
> JGray and Karthik observed yesterday that a regoin open message arrived at the regionserver
but that the regionserver worker thread did not get around to the actually opening until 45
seconds later (region offline for 45 seconds).  We only run a single Worker thread in a regoinserver
processing open, close, and splits.  In this case, a long running close (or two) held up the
worker thread.  We need to run more than a single worker.  A pool of workers?  Should opens
be prioritized?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message