[ https://issues.apache.org/jira/browse/HBASE-16676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15511700#comment-15511700 ]
Andrew Purtell commented on HBASE-16676: ---------------------------------------- That functionality of HBASE-13375 only exists in branch-1.2 . > All RPC requests serviced by PriorityRpcServer in some deploys after > HBASE-13375 > -------------------------------------------------------------------------------- > > Key: HBASE-16676 > URL: https://issues.apache.org/jira/browse/HBASE-16676 > Project: HBase > Issue Type: Bug > Affects Versions: 1.2.0, 1.2.1, 1.2.2, 1.2.3 > Reporter: Andrew Purtell > > I have been trying to track down why 1.2.x won't sometimes pass a 1 billion > row ITBLL run while 0.98.22 and 1.1.6 will always, and a defeat of RPC > prioritization could explain it. We get stuck during the loading phase and > the loader job eventually fails. > All testing is done in an insecure environment under the same UNIX user > (clusterdock) so effectively all ops are issued by the superuser. > Doing unrelated work - or so I thought! - I was looking at object allocations > by YCSB workload by thread and when looking at the RegionServer RPC threads > noticed that for 0.98.22 and 1.1.6, as expected, the vast majority of > allocations are from threads named "B.defaultRpcServer.handler*". In 1.2.0 > and up, instead the vast majority are from threads named > "PriorityRpcServer.handler*" with very little from threads named > "B.defaultRpcServer.handler*". A git bisect to find the change that causes > this leads to HBASE-13375, and so of course this makes sense out of what I am > seeing, but is this really what we want? What about production environments > (insecure and degenerate secure) where all ops are effectively issued by the > superuser? We run one of these at Salesforce. -- This message was sent by Atlassian JIRA (v6.3.4#6332)