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

nkeywal commented on HBASE-7271:
--------------------------------

We've got two lists, hence two locks: we keep the lock on the first one:

{code}
+    synchronized (regionsInProgress) {
+      // If we're there is already a task with this region, we add it to the
+      //  waiting list and return.
+      if (regionsInProgress.contains(regRunnable.getRegionName())) {
+        synchronized (zkEventWorkerWaitingList){
+          zkEventWorkerWaitingList.put(regRunnable.getRegionName(), 
regRunnable);
+        }
+        return;
         ====> We won't touch anymore zkEventWorkerWaitingList, we can release 
the lock
+      }
+
====> We still have the lock on regionsInProgress
+      // No event in progress on this region => we can submit a new task 
immediately.
+      regionsInProgress.add(regRunnable.getRegionName());
{code}
                
> 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, 7271.v2.patch, 7271.v2.patch, 
> 7271.v3.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

Reply via email to