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

Andrew Purtell edited comment on HBASE-16676 at 9/22/16 4:52 PM:
-----------------------------------------------------------------

I plan to commit with the id and subject of HBASE-15315, mark that as fixed in 
1.2.4, and close this issue as dup. 

Edit: Note there is an open release candidate for 1.2.3. Would be reasonable to 
sink that to get this in if testers are finding the RC fails tests due to this 
issue. [~stack] [~busbey] Either way...


was (Author: apurtell):
I plan to commit with the id and subject of HBASE-15315, mark that as fixed in 
1.2.4, and close this issue as dup. 

> 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
>            Assignee: Andrew Purtell
>             Fix For: 1.2.4
>
>         Attachments: HBASE-16676-branch-1.2.patch
>
>
> 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)

Reply via email to