| Bug #61595 | [PATCH] mysql-test/include/wait_for_slave_param.inc timeout logic is incorrect | ||
|---|---|---|---|
| Submitted: | 22 Jun 2011 7:36 | Modified: | 22 Dec 2013 23:58 |
| Reporter: | Stewart Smith | Email Updates: | |
| Status: | Verified | Impact on me: | |
| Category: | MySQL Server: Tests | Severity: | S3 (Non-critical) |
| Version: | 5.1, 5.5 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | Contribution | ||
[22 Jun 2011 7:38]
Stewart Smith
fix slave timeout in mtr
Attachment: slave_timeout_fix.patch (text/x-patch), 476 bytes.
[22 Jun 2011 11:44]
Valeriy Kravchuk
Thank you for the problem report and patch contributed.
[22 Dec 2013 23:58]
Stewart Smith
Is there any chance of this patch being incorporated?
Description: (See patch below) - basically instead of 300 second timeout, it was doing a 30second timeout which we've seen to be hitting in some busy environments (test runs on EC2 with --parallel being high, using actual storage, not --mem). The test code indicates that timeout should be in seconds, and the conversion to tenths of seconds is incorrect. Attached patch fixes How to repeat: mysql-test-run on EC2 with --parallel but without --mem. I suspect we get IO stalls to the scratch space in EC2 instances (combined with ext4 stalls) that lead the timeout to be hit. We could be running 2x builds on an instance with --parallel=auto You can reproduce locally by reducing 300 to say 30 or 3 depending on your system (failure symptoms are exactly the same). Suggested fix: --- a/mysql-test/include/wait_for_slave_param.inc 2011-04-12 22:38:45.000000000 +1000 +++ b/mysql-test/include/wait_for_slave_param.inc 2011-06-21 22:59:13.804854682 +1000 @@ -79,7 +79,7 @@ # mysqltest doesn't provide any better way to multiply by 10 --let $_wait_for_slave_param_zero= 0 ---let $_slave_timeout_counter= $_slave_timeout$zero +--let $_slave_timeout_counter= $_slave_timeout$_wait_for_slave_param_zero --let $_slave_continue= 1 while ($_slave_continue) {