hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Yu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7271) Have a single executor for all zkWorkers in the assignment manager
Date Wed, 05 Dec 2012 17:33:58 GMT

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

Ted Yu commented on HBASE-7271:

+  // We want don't want to have two events on the same region managed simultaneously.
Remove the first 'want' above.
+  private final Set<String> inProgress = new HashSet<String>();
There're many actions in progress. How about naming the above variable regionsInProgress ?
+  private final Multimap<String, RegionRunnable> todo =  HashMultimap.create()
Would zkEventWorkerWaitingList be a better name for todo ?
nit: remove one space before HashMultimap.
+  protected void zkEventWorkersSubmit(final RegionRunnable regRunnable) {
+    synchronized (inProgress) {
+      if (inProgress.contains(regRunnable.getRegionName())) {
+        synchronized (todo){
+          todo.put(regRunnable.getRegionName(), regRunnable);
+        }
+      } else {
nit: if you return from if block, you can save one indent for else block where else keyword
can be omitted.

> Have a single executor for all zkWorkers in the assignment manager
> ------------------------------------------------------------------
>                 Key: HBASE-7271
>                 URL: https://issues.apache.org/jira/browse/HBASE-7271
>             Project: HBase
>          Issue Type: Bug
>          Components: master, Region Assignment
>    Affects Versions: 0.96.0
>            Reporter: nkeywal
>            Assignee: nkeywal
>             Fix For: 0.96.0
>         Attachments: 7271.v1.patch
> The current strategy is to have an array of monothreaded executor, and hash the zk path
to ensure that there are no two events on the same region executed in parallel  
> I think a single executor, as presented in the attached patch, is better because:
> - we're guaranteed to use all threads at any time
> - if managing one of the event takes longer that expected, the slowness is limited to
this region, and not to all regions that have the same hashed/moduloed code
> - For the nodeChildrenChanged, there is no need to choose randomly one of the worker
(or, once again, the risk to get stuck if one of the event takes time to be managed).

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

View raw message