[
https://issues.apache.org/jira/browse/IMPALA-4914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong resolved IMPALA-4914.
-----------------------------------
Resolution: Fixed
Fix Version/s: Impala 2.9.0
IMPALA-4914,IMPALA-4999: remove flaky TestSpillStress
The test does not work as intended and would likely not provide
very good coverage of the different spilling paths, because it
only runs a single simple query. The stress test
(tests/stress/concurrent_select.py) provides much better coverage.
test_mem_usage_scaling.py probably also provides better coverage
that TestSpillStress in its current form.
Change-Id: Ie792d64dc88f682066c13e559918d72d76b31b71
Reviewed-on: http://gerrit.cloudera.org:8080/6437
Reviewed-by: Michael Brown <mi...@cloudera.com>
Tested-by: Impala Public Jenkins
---
> TestSpillStress makes flawed assumptions about running concurrently
> -------------------------------------------------------------------
>
> Key: IMPALA-4914
> URL: https://issues.apache.org/jira/browse/IMPALA-4914
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
> Affects Versions: Impala 2.9.0
> Reporter: Michael Brown
> Assignee: Tim Armstrong
> Fix For: Impala 2.9.0
>
>
> I took a look at TestSpillStress and found a bunch of problems with it.
> # It's not being run, because its workload isn't being run exhaustively
> # It can't run, because it doesn't set up a client properly.
> # It looks like it was intended to run in parallel fashion, but custom
> cluster tests don't run in parallel.
> The evidence for my claim of #3 is due to the fact that it uses the
> agg_stress workload, which says:
> {noformat}
> # This query forces many joins and aggregations with spilling
> # and can expose race conditions in the spilling code if run in parallel
> {noformat}
> 1 and 2 could be fixed very quickly and were fixed at
> https://gerrit.cloudera.org/#/c/6002/
> 3 is a different thing and requires some thought. We don't have any mechanism
> to run custom cluster tests in any sort of parallel way. All custom cluster
> tests are serial, even though they lack the serial mark. The reason this is
> the case is because most custom cluster tests involve restarting impalad on
> every *method*. We can't have methods run in parallel if they will be
> restarting on top of each other. As such, custom cluster tests are invoked
> differently than other e2e tests, and the invocation does not include {{-n}},
> which causes tests to run in parallel.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
