[
https://issues.apache.org/jira/browse/IMPALA-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989227#comment-16989227
]
ASF subversion and git services commented on IMPALA-9202:
---------------------------------------------------------
Commit 85e138d3f0178a349aab3c11264a3c9b9f029533 in impala's branch
refs/heads/master from Bikramjeet Vig
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=85e138d ]
IMPALA-9202: Fix flakiness in test_executor_groups
Some tests in test_executor_groups immediately tried fetching the query
profile after executing it asynchronously to verify if the query was
queued. However there is a small window between the exec rpc returning
and the query being queued during which the query profile does not
contain any info about the query being queued. This was causing some
asserts in the test to fail.
Change-Id: I47070045250a12d86c99f9a30a956a268be5fa7e
Reviewed-on: http://gerrit.cloudera.org:8080/14810
Reviewed-by: Impala Public Jenkins <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>
> Fix flakiness in TestExecutorGroups
> -----------------------------------
>
> Key: IMPALA-9202
> URL: https://issues.apache.org/jira/browse/IMPALA-9202
> Project: IMPALA
> Issue Type: Bug
> Affects Versions: Impala 3.4.0
> Reporter: Bikramjeet Vig
> Assignee: Bikramjeet Vig
> Priority: Minor
> Labels: broken-build, flaky, flaky-test
>
> test_executor_groups.TestExecutorGroups.test_admission_slots failed on an
> assertion recently with the following stacktrace
> {noformat}
> custom_cluster/test_executor_groups.py:215: in test_admission_slots
> assert ("Initial admission queue reason: Not enough admission control
> slots "
> E assert 'Initial admission queue reason: Not enough admission control
> slots available on host' in 'Query (id=0445eb75d4842dce:219df01e00000000):\n
> DEBUG MODE WARNING: Query profile created while running a DEBUG buil...0)\n
> - NumRowsFetchedFromCache: 0 (0)\n - RowMaterializationRate: 0\n -
> RowMaterializationTimer: 0.000ns\n
> {noformat}
> On investigating the logs, it seems like the query did in fact get queued
> with the expected reason. The only reason I can think of that it failed to
> appear on profile is that the profile was fetched before the admission reason
> could be added to the profile. This happened in an ASAN build so I am
> assuming the slowness in execution contributed to widening the window in
> which this can happen.
> from the logs:
> {noformat}
> I1104 18:18:34.144309 113361 impala-server.cc:1046]
> 0445eb75d4842dce:219df01e00000000] Registered query
> query_id=0445eb75d4842dce:219df01e00000000
> session_id=da467385483f4fb3:16683a81d25fe79e
> I1104 18:18:34.144951 113361 Frontend.java:1256]
> 0445eb75d4842dce:219df01e00000000] Analyzing query: select * from
> functional_parquet.alltypestiny where month < 3 and id +
> random() < sleep(500); db: default
> I1104 18:18:34.149049 113361 BaseAuthorizationChecker.java:96]
> 0445eb75d4842dce:219df01e00000000] Authorization check took 4 ms
> I1104 18:18:34.149219 113361 Frontend.java:1297]
> 0445eb75d4842dce:219df01e00000000] Analysis and authorization finished.
> I1104 18:18:34.163229 113885 scheduler.cc:548]
> 0445eb75d4842dce:219df01e00000000] Exec at coord is false
> I1104 18:18:34.163945 113885 admission-controller.cc:1295]
> 0445eb75d4842dce:219df01e00000000] Trying to admit
> id=0445eb75d4842dce:219df01e00000000 in pool_name=default-pool
> executor_group_name=default-pool-group1 per_host_mem_estimate=176.02 MB
> dedicated_coord_mem_estimate=100.02 MB max_requests=-1 (configured
> statically) max_queued=200 (configured statically) max_mem=-1.00 B
> (configured statically)
> I1104 18:18:34.164203 113885 admission-controller.cc:1307]
> 0445eb75d4842dce:219df01e00000000] Stats: agg_num_running=1,
> agg_num_queued=0, agg_mem_reserved=8.00 KB,
> local_host(local_mem_admitted=452.05 MB, num_admitted_running=1,
> num_queued=0, backend_mem_reserved=8.00 KB)
> I1104 18:18:34.164383 113885 admission-controller.cc:902]
> 0445eb75d4842dce:219df01e00000000] Queuing, query
> id=0445eb75d4842dce:219df01e00000000 reason: Not enough admission control
> slots available on host
> impala-ec2-centos74-r4-4xlarge-ondemand-1f88.vpc.cloudera.com:22002. Needed 1
> slots but 1/1 are already in use.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
