You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Jimmy Xiang (JIRA)" <ji...@apache.org> on 2012/12/05 17:38:59 UTC

[jira] [Commented] (HBASE-7271) Have a single executor for all zkWorkers in the assignment manager

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

Jimmy Xiang commented on HBASE-7271:
------------------------------------

Looked at the patch.  The idea is great.

{code}
+  // In a multimap, the put order is kept when we retrieve the collection back. We need this
+  //  as we want the events to be managed in the same order as we received them.
{code}

Are we sure the order is kept?  It seems to me HashMultiMap uses just a regular HashSet to store the values which don't keep the order.
If so, we can just use a hash map from region name to a linked list of RegionRunnable instead.
                
> 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: Jimmy Xiang
>             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