hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Busbey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-16676) All RPC requests serviced by PriorityRpcServer in some deploys after HBASE-13375
Date Thu, 22 Sep 2016 04:56:20 GMT

    [ 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

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

View raw message