[
https://issues.apache.org/jira/browse/HBASE-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852954#action_12852954
]
Jonathan Gray commented on HBASE-2405:
--------------------------------------
Thanks for opening this stack.
I'm unsure if we really need multi-threaded Workers to process the messages, or
if we should just have the worker we have now be able to do things more
asynchronously. Right now it's bad that we allow any compacting outside of the
CompactSplitThread, we should be shuffling everything through there so that we
respect compaction limits. I'm thinking we need some way to allow things like
compactions to know that they need to trigger some other action once completed.
Maybe the compaction requests could carry some reference to an optional
callback method... seems like there's a bunch of cool stuff we could do with
that.
I'm worried about introducing parallelism where we don't currently have it so
think we should try to avoid it where possible. As long as we don't block in
the thread processing messages, should not be a problem.
Stack, how does this relate to possible changes from the master rewrite. If
the regionservers are no longer just processing a message queue coming from the
master, and instead are processing events triggered by zk watchers and such,
maybe a move towards parallelism in message processing is necessary anyways.
Thoughts?
> 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.
