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