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

Sergey Shelukhin commented on HBASE-5258:
-----------------------------------------

There may be potential for using info about region server load that is more 
realtime/critical than metrics channel, in master, for balancing/etc. Probably 
not important short term.
W.r.t. zk - why cannot master read zk nodes and apply rules too? ZK nodes may 
need to be made smarter for this purpose. 
Assuming RSs will have to talk to ZK anyway, for large clusters it will avoid 
extra all-to-one communication. Although master reading ZK to make decisions 
may introduce additional delay, especially if master just watches the nodes and 
builds up internal state, instead of querying entire state periodically.
Regardless, does having different coprocessors on the regions of the same table 
make sense? If user has logic relying on coprocessors for some data querying or 
correctness it seems dangerous. 

                
> Move coprocessors set out of RegionLoad
> ---------------------------------------
>
>                 Key: HBASE-5258
>                 URL: https://issues.apache.org/jira/browse/HBASE-5258
>             Project: HBase
>          Issue Type: Task
>            Reporter: Ted Yu
>            Priority: Critical
>
> When I worked on HBASE-5256, I revisited the code related to Ser/De of 
> coprocessors set in RegionLoad.
> I think the rationale for embedding coprocessors set is for maximum 
> flexibility where each region can load different coprocessors.
> This flexibility is causing extra cost in the region server to Master 
> communication and increasing the footprint of Master heap.
> Would HServerLoad be a better place for this set ?
> If required, region server should calculate disparity of loaded coprocessors 
> among regions and send report through HServerLoad

--
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