Jason Fehr created IMPALA-15612:
-----------------------------------

             Summary: Admission Control More Specific Rule Not Overriding in 
ROOT Pool
                 Key: IMPALA-15612
                 URL: https://issues.apache.org/jira/browse/IMPALA-15612
             Project: IMPALA
          Issue Type: Bug
    Affects Versions: Impala 5.1.0
            Reporter: Jason Fehr


The doc:

https://impala.apache.org/docs/build/html/topics/impala_admission_config.html

we see:

More Specific Rules Override The Less Specific

 

Steps to Repro:

1) Add quotas to fair-scheduler.xml where wildcard limit is larger than 
specific user limit

eg:


{noformat}
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<allocations>
    <queue name="root">
        <weight>1.0</weight>
        <schedulingPolicy>fair</schedulingPolicy>
        <aclSubmitApps>*</aclSubmitApps>
        <aclAdministerApps>*</aclAdministerApps>
        <userQueryLimit>
            <user></user>{*}
            <totalCount>3</totalCount>
        </userQueryLimit>
        <userQueryLimit>
            <user>userA</user>
            <totalCount>2</totalCount>
        </userQueryLimit>
        <queue name="default">
            <weight>1.0</weight>
            <schedulingPolicy>fair</schedulingPolicy>
            <!-- Set a huge amount of memory to enable memory based admission 
control -->
            <maxResources>50000000 mb, 0 vcores</maxResources>
        </queue>
    </queue>
    <defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy>
    <queuePlacementPolicy>
        <!-- rule cannot create new queue -->
        <rule name="specified" create="false"/>
        <rule name="default"/>
    </queuePlacementPolicy>
</allocations>
{noformat}
                

2) When running as "userA",launch more than the small limit:

eg:

{noformat}
impala-shell -q "select * from functional.alltypes;"
impala-shell -q "select * from functional.alltypes;"
impala-shell -q "select * from functional.alltypes;"
{noformat}


3) Note that all 3 are OK and running (expected 3rd to fail due to exceed limit 
of two)

4) Try one more, and then we see:

Rejected query from pool root.default: current per-user load 3 for user 'userA' 
is at or above the user limit 2 in pool 'root'

The message says current is 3, which it never should be, but interestingly it 
shows the user limit as 2 which is the correct, more specific limit



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to