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

Reply via email to