[
https://issues.apache.org/jira/browse/HBASE-16676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15547558#comment-15547558
]
Mikhail Antonov commented on HBASE-16676:
-----------------------------------------
+1 (and [~apurtell] I feel sorry for the time spent debugging this, as I made
the patch for HBASE-13375 to begin with...)
> 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
> 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)
