Commit 5ea51287 authored by knielsen@ymer.(none)'s avatar knielsen@ymer.(none)

BUG#19951: Race conditions in test wait_timeout.

Fix random failures in test 'wait_timeout' that depend on exact timing.

1. Force a reconnect initially if necessary, as otherwise slow startup
might have caused a connection timeout before the test can even start.

2. Explicitly disconnect the first connection to remove confusion about
which connection aborts from timeout, causing test failure.
parent 50477229
select 0;
0
0
flush status;
select 1;
1
1
......
......@@ -9,16 +9,20 @@
# Connect with another connection and reset counters
--disable_query_log
connect (wait_con,localhost,root,,test,,);
flush status; # Reset counters
connection wait_con;
set session wait_timeout=100;
let $retries=300;
let $aborted_clients = `SHOW STATUS LIKE 'aborted_clients'`;
set @aborted_clients= 0;
--enable_query_log
# Disable reconnect and do the query
connection default;
# If slow host (Valgrind...), we may have already timed out here.
# So force a reconnect if necessary, using a dummy query. And issue a
# 'flush status' to reset the 'aborted_clients' counter.
--enable_reconnect
select 0;
flush status;
--disable_reconnect
select 1;
......@@ -46,6 +50,9 @@ connection default;
select 2;
--enable_reconnect
select 3;
# Disconnect so that we will not be confused by a future abort from this
# connection.
disconnect default
#
# Do the same test as above on a TCP connection
......@@ -56,7 +63,6 @@ select 3;
connection wait_con;
flush status; # Reset counters
let $retries=300;
let $aborted_clients = `SHOW STATUS LIKE 'aborted_clients'`;
set @aborted_clients= 0;
--enable_query_log
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment