Andrew Purtell created HBASE-16676:

             Summary: All RPC requests serviced by PriorityRpcServer in some 
deploys after HBASE-13375
                 Key: HBASE-16676
             Project: HBase
          Issue Type: Bug
    Affects Versions: 1.2.3, 1.2.2, 1.2.1, 1.2.0, 2.0.0, 1.3.0, 1.4.0
            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