[
https://issues.apache.org/jira/browse/HBASE-16676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15512141#comment-15512141
]
Sean Busbey commented on HBASE-16676:
-------------------------------------
This is effectively a backport of HBASE-15315, right? The original reasoning
for that not ending up in branch-1.2 was that it would change operational
behavior too much for a maintenance release.
It sounds like another ~6 months of time on the 1.2 branch has led to a belief
that the downside of leaving this in place is severe enough to change that
decision. Is that right? If so, that sounds reasonable to me.
ping [~eclark] since he was the other person in favor of leaving HBASE-15315
out of 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
> 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)
