[
https://issues.apache.org/jira/browse/KUDU-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16044815#comment-16044815
]
Alexey Serbin commented on KUDU-2037:
-------------------------------------
Posted a patch for review to address the test flakiness issue:
http://gerrit.cloudera.org:8080/7138
The issue with the build up of GetTableLocations() requests in the client- and
the master-side queues will be addressed separately.
> ts_recovery-itest flaky since KUDU-1034 fixed
> ---------------------------------------------
>
> Key: KUDU-2037
> URL: https://issues.apache.org/jira/browse/KUDU-2037
> Project: Kudu
> Issue Type: Bug
> Components: client, test
> Affects Versions: 1.4.0
> Reporter: Todd Lipcon
> Assignee: Alexey Serbin
> Priority: Critical
>
> ts_recovery-itest is quite flaky lately (~50% in TSAN builds). I was able to
> reproduce the flakiness reliably doing:
> {code}
> taskset -c 0-1 ./build-support/run-test.sh
> ./build/latest/bin/ts_recovery-itest --gtest_filter=\*Orphan\*
> -stress-cpu-threads 4
> {code}
> I tracked the flakiness down to being introduced by KUDU-1034
> (4263b037844fca595a35f99479fbb5765ba7a443). The issue seems to be that the
> test sets a low timeout such that a large number of requests time out, and
> with the new behavior introduced by that commit, we end up hammering the
> master and unable to make progress.
> Unclear if this is a feature (and we need to update the test) or a bug
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
