2009-03-12 23:27:35 +01:00
|
|
|
# Start with thread_handling=pool-of-threads
|
|
|
|
# and run a number of tests
|
|
|
|
|
|
|
|
-- source include/have_pool_of_threads.inc
|
2019-08-30 15:06:54 +02:00
|
|
|
-- source include/default_optimizer_switch.inc
|
|
|
|
|
2011-12-15 09:21:15 +01:00
|
|
|
SET optimizer_switch='outer_join_with_cache=off';
|
Added option --staging-run to mysql-test-run to mark slow, not important tests, to not be run in staging trees
Use MY_MUTEX_INIT_FAST for pool mutex
mysql-test/mysql-test-run.pl:
Added option --staging-run
Added information about --parallell=# to help message
mysql-test/suite/federated/federated_server.test:
Slow test, don't run with --staging-run
mysql-test/suite/maria/t/maria-preload.test:
Slow test, don't run with --staging-run
mysql-test/suite/rpl/t/rpl_optimize.test:
Slow test, don't run with --staging-run
mysql-test/suite/rpl/t/rpl_relayrotate.test:
Slow test, don't run with --staging-run
mysql-test/suite/rpl/t/rpl_row_001.test:
Slow test, don't run with --staging-run
mysql-test/suite/rpl/t/rpl_row_mysqlbinlog.test:
Slow test, don't run with --staging-run
mysql-test/suite/rpl/t/rpl_row_sp003.test:
Slow test, don't run with --staging-run
mysql-test/suite/rpl/t/rpl_start_stop_slave.test:
Slow test, don't run with --staging-run
mysql-test/t/compress.test:
Slow test, don't run with --staging-run
mysql-test/t/count_distinct3.test:
Slow test, don't run with --staging-run
mysql-test/t/index_merge_innodb.test:
Slow test, don't run with --staging-run
mysql-test/t/information_schema_all_engines.test:
Slow test, don't run with --staging-run
mysql-test/t/innodb_mysql.test:
Slow test, don't run with --staging-run
mysql-test/t/pool_of_threads.test:
Slow test, don't run with --staging-run
mysql-test/t/preload.test:
Slow test, don't run with --staging-run
mysql-test/t/ssl.test:
Slow test, don't run with --staging-run
mysql-test/t/ssl_compress.test:
Slow test, don't run with --staging-run
mysql-test/valgrind.supp:
Suppress warnings from SuSE 11.1 on x86
sql/scheduler.cc:
Use MY_MUTEX_INIT_FAST for pool mutex
2009-06-05 17:35:22 +02:00
|
|
|
# Slow test, don't run during staging part
|
|
|
|
-- source include/not_staging.inc
|
2011-01-03 15:33:39 +01:00
|
|
|
-- source include/long_test.inc
|
2009-03-12 23:27:35 +01:00
|
|
|
-- source include/common-tests.inc
|
2019-08-30 15:06:54 +02:00
|
|
|
SET optimizer_switch=default;
|
2009-03-18 16:46:32 +01:00
|
|
|
|
|
|
|
# Test that we cannot have more simultaneous connections than
|
|
|
|
# --thread-pool-size on the standard port, but _can_ have additional
|
|
|
|
# connections on the extra port.
|
|
|
|
|
|
|
|
# First set two connections running, and check that extra connection
|
MDEV-10100 main.pool_of_threads fails sporadically in buildbot
The patch fixes two test failures:
- on slow builders, sometimes a connection attempt which should
fail due to the exceeded number of thread_pool_max_threads
actually succeeds;
- on even slow builders, MTR sometimes cannot establish the
initial connection, and check-testcase fails prior to the
test start
The problem with check-testcase was caused by connect-timeout=2
which was set for all clients in the test config file. On slow
builders it might be not enough.
There is no way to override it for the pre-test check, so it needed
to be substantially increased or removed.
The other problem was caused by a race condition between sleeps
that the test performs in existing connections and the connect
timeout for the connection attempt which was expected to fail.
If sleeps finished before the connect-timeout was exceeded, it
would allow the connection to succeed.
To solve each problem without making the other one worse,
connect-timeout should be configured dynamically during the test.
Due to the nature of the test (all connections must be busy
at the moment when we need to change the timeout, and cannot execute
SET GLOBAL ...), it needs to be done independently from the server.
The solution:
- recognize 'connect_timeout' as a connection option in mysqltest's
"connect" command;
- remove connect-timeout from the test configuration file;
- use the new connect_timeout option for those connections which
are expected to fail;
- re-arrange the test flow to allow running a huge SLEEP
without affecting the test execution time (because it would be
interrupted after the main test flow is finished).
The test is still subject to false negatives, e.g. if the connection
fails due to timeout rather than due to the exceeded number of
allowed threads, or if the connection on extra port succeeds due
to a race condition and not because the special logic for the extra
port. But those false negatives have always been possible there
on slow builders, they should not be critical because faster builders
should catch such failures if they appear.
2017-01-01 19:06:03 +01:00
|
|
|
# on normal port fails due to --thread-pool-max-threads=2.
|
|
|
|
# We can afford using a really long sleep, because we won't wait
|
|
|
|
# till it ends, we'll interrupt it as soon as we don't need it anymore
|
|
|
|
|
2009-03-18 16:46:32 +01:00
|
|
|
connection default;
|
MDEV-10100 main.pool_of_threads fails sporadically in buildbot
The patch fixes two test failures:
- on slow builders, sometimes a connection attempt which should
fail due to the exceeded number of thread_pool_max_threads
actually succeeds;
- on even slow builders, MTR sometimes cannot establish the
initial connection, and check-testcase fails prior to the
test start
The problem with check-testcase was caused by connect-timeout=2
which was set for all clients in the test config file. On slow
builders it might be not enough.
There is no way to override it for the pre-test check, so it needed
to be substantially increased or removed.
The other problem was caused by a race condition between sleeps
that the test performs in existing connections and the connect
timeout for the connection attempt which was expected to fail.
If sleeps finished before the connect-timeout was exceeded, it
would allow the connection to succeed.
To solve each problem without making the other one worse,
connect-timeout should be configured dynamically during the test.
Due to the nature of the test (all connections must be busy
at the moment when we need to change the timeout, and cannot execute
SET GLOBAL ...), it needs to be done independently from the server.
The solution:
- recognize 'connect_timeout' as a connection option in mysqltest's
"connect" command;
- remove connect-timeout from the test configuration file;
- use the new connect_timeout option for those connections which
are expected to fail;
- re-arrange the test flow to allow running a huge SLEEP
without affecting the test execution time (because it would be
interrupted after the main test flow is finished).
The test is still subject to false negatives, e.g. if the connection
fails due to timeout rather than due to the exceeded number of
allowed threads, or if the connection on extra port succeeds due
to a race condition and not because the special logic for the extra
port. But those false negatives have always been possible there
on slow builders, they should not be critical because faster builders
should catch such failures if they appear.
2017-01-01 19:06:03 +01:00
|
|
|
--let $con1_id= `SELECT CONNECTION_ID()`
|
2013-05-23 14:52:48 +02:00
|
|
|
|
MDEV-10100 main.pool_of_threads fails sporadically in buildbot
The patch fixes two test failures:
- on slow builders, sometimes a connection attempt which should
fail due to the exceeded number of thread_pool_max_threads
actually succeeds;
- on even slow builders, MTR sometimes cannot establish the
initial connection, and check-testcase fails prior to the
test start
The problem with check-testcase was caused by connect-timeout=2
which was set for all clients in the test config file. On slow
builders it might be not enough.
There is no way to override it for the pre-test check, so it needed
to be substantially increased or removed.
The other problem was caused by a race condition between sleeps
that the test performs in existing connections and the connect
timeout for the connection attempt which was expected to fail.
If sleeps finished before the connect-timeout was exceeded, it
would allow the connection to succeed.
To solve each problem without making the other one worse,
connect-timeout should be configured dynamically during the test.
Due to the nature of the test (all connections must be busy
at the moment when we need to change the timeout, and cannot execute
SET GLOBAL ...), it needs to be done independently from the server.
The solution:
- recognize 'connect_timeout' as a connection option in mysqltest's
"connect" command;
- remove connect-timeout from the test configuration file;
- use the new connect_timeout option for those connections which
are expected to fail;
- re-arrange the test flow to allow running a huge SLEEP
without affecting the test execution time (because it would be
interrupted after the main test flow is finished).
The test is still subject to false negatives, e.g. if the connection
fails due to timeout rather than due to the exceeded number of
allowed threads, or if the connection on extra port succeeds due
to a race condition and not because the special logic for the extra
port. But those false negatives have always been possible there
on slow builders, they should not be critical because faster builders
should catch such failures if they appear.
2017-01-01 19:06:03 +01:00
|
|
|
send SELECT sleep(50);
|
2012-01-02 10:13:53 +01:00
|
|
|
--sleep 1
|
2009-03-18 16:46:32 +01:00
|
|
|
|
|
|
|
connect(con2,localhost,root,,);
|
MDEV-10100 main.pool_of_threads fails sporadically in buildbot
The patch fixes two test failures:
- on slow builders, sometimes a connection attempt which should
fail due to the exceeded number of thread_pool_max_threads
actually succeeds;
- on even slow builders, MTR sometimes cannot establish the
initial connection, and check-testcase fails prior to the
test start
The problem with check-testcase was caused by connect-timeout=2
which was set for all clients in the test config file. On slow
builders it might be not enough.
There is no way to override it for the pre-test check, so it needed
to be substantially increased or removed.
The other problem was caused by a race condition between sleeps
that the test performs in existing connections and the connect
timeout for the connection attempt which was expected to fail.
If sleeps finished before the connect-timeout was exceeded, it
would allow the connection to succeed.
To solve each problem without making the other one worse,
connect-timeout should be configured dynamically during the test.
Due to the nature of the test (all connections must be busy
at the moment when we need to change the timeout, and cannot execute
SET GLOBAL ...), it needs to be done independently from the server.
The solution:
- recognize 'connect_timeout' as a connection option in mysqltest's
"connect" command;
- remove connect-timeout from the test configuration file;
- use the new connect_timeout option for those connections which
are expected to fail;
- re-arrange the test flow to allow running a huge SLEEP
without affecting the test execution time (because it would be
interrupted after the main test flow is finished).
The test is still subject to false negatives, e.g. if the connection
fails due to timeout rather than due to the exceeded number of
allowed threads, or if the connection on extra port succeeds due
to a race condition and not because the special logic for the extra
port. But those false negatives have always been possible there
on slow builders, they should not be critical because faster builders
should catch such failures if they appear.
2017-01-01 19:06:03 +01:00
|
|
|
--let $con2_id= `SELECT CONNECTION_ID()`
|
|
|
|
|
|
|
|
send SELECT sleep(50);
|
2012-01-02 10:13:53 +01:00
|
|
|
--sleep 0.5
|
2009-03-18 16:46:32 +01:00
|
|
|
|
|
|
|
--disable_abort_on_error
|
|
|
|
--disable_result_log
|
|
|
|
--disable_query_log
|
MDEV-10100 main.pool_of_threads fails sporadically in buildbot
The patch fixes two test failures:
- on slow builders, sometimes a connection attempt which should
fail due to the exceeded number of thread_pool_max_threads
actually succeeds;
- on even slow builders, MTR sometimes cannot establish the
initial connection, and check-testcase fails prior to the
test start
The problem with check-testcase was caused by connect-timeout=2
which was set for all clients in the test config file. On slow
builders it might be not enough.
There is no way to override it for the pre-test check, so it needed
to be substantially increased or removed.
The other problem was caused by a race condition between sleeps
that the test performs in existing connections and the connect
timeout for the connection attempt which was expected to fail.
If sleeps finished before the connect-timeout was exceeded, it
would allow the connection to succeed.
To solve each problem without making the other one worse,
connect-timeout should be configured dynamically during the test.
Due to the nature of the test (all connections must be busy
at the moment when we need to change the timeout, and cannot execute
SET GLOBAL ...), it needs to be done independently from the server.
The solution:
- recognize 'connect_timeout' as a connection option in mysqltest's
"connect" command;
- remove connect-timeout from the test configuration file;
- use the new connect_timeout option for those connections which
are expected to fail;
- re-arrange the test flow to allow running a huge SLEEP
without affecting the test execution time (because it would be
interrupted after the main test flow is finished).
The test is still subject to false negatives, e.g. if the connection
fails due to timeout rather than due to the exceeded number of
allowed threads, or if the connection on extra port succeeds due
to a race condition and not because the special logic for the extra
port. But those false negatives have always been possible there
on slow builders, they should not be critical because faster builders
should catch such failures if they appear.
2017-01-01 19:06:03 +01:00
|
|
|
connect(con3,localhost,root,,,,,connect_timeout=2);
|
2009-03-18 16:46:32 +01:00
|
|
|
--enable_query_log
|
|
|
|
--enable_result_log
|
|
|
|
--enable_abort_on_error
|
|
|
|
let $error = $mysql_errno;
|
|
|
|
if (!$error)
|
|
|
|
{
|
2011-12-18 23:03:35 +01:00
|
|
|
--echo # -- Error: managed to establish more than --thread_pool_max_threads connections
|
2009-03-18 16:46:32 +01:00
|
|
|
}
|
|
|
|
if ($error)
|
|
|
|
{
|
2011-12-18 23:03:35 +01:00
|
|
|
--echo # -- Success: more than --thread_pool_max_threads normal connections not possible
|
2009-03-18 16:46:32 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
connect(extracon,127.0.0.1,root,,test,$MASTER_EXTRA_PORT,);
|
|
|
|
connection extracon;
|
|
|
|
SELECT 'Connection on extra port ok';
|
|
|
|
|
MDEV-10100 main.pool_of_threads fails sporadically in buildbot
The patch fixes two test failures:
- on slow builders, sometimes a connection attempt which should
fail due to the exceeded number of thread_pool_max_threads
actually succeeds;
- on even slow builders, MTR sometimes cannot establish the
initial connection, and check-testcase fails prior to the
test start
The problem with check-testcase was caused by connect-timeout=2
which was set for all clients in the test config file. On slow
builders it might be not enough.
There is no way to override it for the pre-test check, so it needed
to be substantially increased or removed.
The other problem was caused by a race condition between sleeps
that the test performs in existing connections and the connect
timeout for the connection attempt which was expected to fail.
If sleeps finished before the connect-timeout was exceeded, it
would allow the connection to succeed.
To solve each problem without making the other one worse,
connect-timeout should be configured dynamically during the test.
Due to the nature of the test (all connections must be busy
at the moment when we need to change the timeout, and cannot execute
SET GLOBAL ...), it needs to be done independently from the server.
The solution:
- recognize 'connect_timeout' as a connection option in mysqltest's
"connect" command;
- remove connect-timeout from the test configuration file;
- use the new connect_timeout option for those connections which
are expected to fail;
- re-arrange the test flow to allow running a huge SLEEP
without affecting the test execution time (because it would be
interrupted after the main test flow is finished).
The test is still subject to false negatives, e.g. if the connection
fails due to timeout rather than due to the exceeded number of
allowed threads, or if the connection on extra port succeeds due
to a race condition and not because the special logic for the extra
port. But those false negatives have always been possible there
on slow builders, they should not be critical because faster builders
should catch such failures if they appear.
2017-01-01 19:06:03 +01:00
|
|
|
# Here, sleep just for slightly longer than 5 sec to trigger MDEV-4566
|
|
|
|
# (abort in interruptible wait connection check).
|
|
|
|
send SELECT sleep(5.5);
|
|
|
|
|
|
|
|
|
2009-03-18 16:46:32 +01:00
|
|
|
connect(extracon2,127.0.0.1,root,,test,$MASTER_EXTRA_PORT,);
|
|
|
|
connection extracon2;
|
|
|
|
SELECT 'Connection on extra port 2 ok';
|
|
|
|
|
|
|
|
--disable_abort_on_error
|
|
|
|
--disable_result_log
|
|
|
|
--disable_query_log
|
MDEV-10100 main.pool_of_threads fails sporadically in buildbot
The patch fixes two test failures:
- on slow builders, sometimes a connection attempt which should
fail due to the exceeded number of thread_pool_max_threads
actually succeeds;
- on even slow builders, MTR sometimes cannot establish the
initial connection, and check-testcase fails prior to the
test start
The problem with check-testcase was caused by connect-timeout=2
which was set for all clients in the test config file. On slow
builders it might be not enough.
There is no way to override it for the pre-test check, so it needed
to be substantially increased or removed.
The other problem was caused by a race condition between sleeps
that the test performs in existing connections and the connect
timeout for the connection attempt which was expected to fail.
If sleeps finished before the connect-timeout was exceeded, it
would allow the connection to succeed.
To solve each problem without making the other one worse,
connect-timeout should be configured dynamically during the test.
Due to the nature of the test (all connections must be busy
at the moment when we need to change the timeout, and cannot execute
SET GLOBAL ...), it needs to be done independently from the server.
The solution:
- recognize 'connect_timeout' as a connection option in mysqltest's
"connect" command;
- remove connect-timeout from the test configuration file;
- use the new connect_timeout option for those connections which
are expected to fail;
- re-arrange the test flow to allow running a huge SLEEP
without affecting the test execution time (because it would be
interrupted after the main test flow is finished).
The test is still subject to false negatives, e.g. if the connection
fails due to timeout rather than due to the exceeded number of
allowed threads, or if the connection on extra port succeeds due
to a race condition and not because the special logic for the extra
port. But those false negatives have always been possible there
on slow builders, they should not be critical because faster builders
should catch such failures if they appear.
2017-01-01 19:06:03 +01:00
|
|
|
connect(extracon3,127.0.0.1,root,,test,$MASTER_EXTRA_PORT,,connect_timeout=2);
|
2009-03-18 16:46:32 +01:00
|
|
|
--enable_query_log
|
|
|
|
--enable_result_log
|
|
|
|
--enable_abort_on_error
|
|
|
|
let $error = $mysql_errno;
|
|
|
|
if (!$error)
|
|
|
|
{
|
|
|
|
--echo # -- Error: managed to establish more than --extra-max-connections + 1 connections
|
|
|
|
}
|
|
|
|
if ($error)
|
|
|
|
{
|
|
|
|
--echo # -- Success: more than --extra-max-connections + 1 normal connections not possible
|
|
|
|
}
|
|
|
|
|
MDEV-10100 main.pool_of_threads fails sporadically in buildbot
The patch fixes two test failures:
- on slow builders, sometimes a connection attempt which should
fail due to the exceeded number of thread_pool_max_threads
actually succeeds;
- on even slow builders, MTR sometimes cannot establish the
initial connection, and check-testcase fails prior to the
test start
The problem with check-testcase was caused by connect-timeout=2
which was set for all clients in the test config file. On slow
builders it might be not enough.
There is no way to override it for the pre-test check, so it needed
to be substantially increased or removed.
The other problem was caused by a race condition between sleeps
that the test performs in existing connections and the connect
timeout for the connection attempt which was expected to fail.
If sleeps finished before the connect-timeout was exceeded, it
would allow the connection to succeed.
To solve each problem without making the other one worse,
connect-timeout should be configured dynamically during the test.
Due to the nature of the test (all connections must be busy
at the moment when we need to change the timeout, and cannot execute
SET GLOBAL ...), it needs to be done independently from the server.
The solution:
- recognize 'connect_timeout' as a connection option in mysqltest's
"connect" command;
- remove connect-timeout from the test configuration file;
- use the new connect_timeout option for those connections which
are expected to fail;
- re-arrange the test flow to allow running a huge SLEEP
without affecting the test execution time (because it would be
interrupted after the main test flow is finished).
The test is still subject to false negatives, e.g. if the connection
fails due to timeout rather than due to the exceeded number of
allowed threads, or if the connection on extra port succeeds due
to a race condition and not because the special logic for the extra
port. But those false negatives have always been possible there
on slow builders, they should not be critical because faster builders
should catch such failures if they appear.
2017-01-01 19:06:03 +01:00
|
|
|
connection extracon2;
|
|
|
|
--replace_result $con1_id <default_connection_ID>
|
|
|
|
eval KILL QUERY $con1_id;
|
|
|
|
--replace_result $con2_id <con2_connection_ID>
|
|
|
|
eval KILL QUERY $con2_id;
|
|
|
|
|
2009-03-18 16:46:32 +01:00
|
|
|
connection default;
|
2020-10-30 17:23:53 +01:00
|
|
|
--error ER_QUERY_INTERRUPTED
|
2009-03-18 16:46:32 +01:00
|
|
|
--reap
|
|
|
|
connection con2;
|
2020-10-30 17:23:53 +01:00
|
|
|
--error ER_QUERY_INTERRUPTED
|
2009-03-18 16:46:32 +01:00
|
|
|
--reap
|
MDEV-10100 main.pool_of_threads fails sporadically in buildbot
The patch fixes two test failures:
- on slow builders, sometimes a connection attempt which should
fail due to the exceeded number of thread_pool_max_threads
actually succeeds;
- on even slow builders, MTR sometimes cannot establish the
initial connection, and check-testcase fails prior to the
test start
The problem with check-testcase was caused by connect-timeout=2
which was set for all clients in the test config file. On slow
builders it might be not enough.
There is no way to override it for the pre-test check, so it needed
to be substantially increased or removed.
The other problem was caused by a race condition between sleeps
that the test performs in existing connections and the connect
timeout for the connection attempt which was expected to fail.
If sleeps finished before the connect-timeout was exceeded, it
would allow the connection to succeed.
To solve each problem without making the other one worse,
connect-timeout should be configured dynamically during the test.
Due to the nature of the test (all connections must be busy
at the moment when we need to change the timeout, and cannot execute
SET GLOBAL ...), it needs to be done independently from the server.
The solution:
- recognize 'connect_timeout' as a connection option in mysqltest's
"connect" command;
- remove connect-timeout from the test configuration file;
- use the new connect_timeout option for those connections which
are expected to fail;
- re-arrange the test flow to allow running a huge SLEEP
without affecting the test execution time (because it would be
interrupted after the main test flow is finished).
The test is still subject to false negatives, e.g. if the connection
fails due to timeout rather than due to the exceeded number of
allowed threads, or if the connection on extra port succeeds due
to a race condition and not because the special logic for the extra
port. But those false negatives have always been possible there
on slow builders, they should not be critical because faster builders
should catch such failures if they appear.
2017-01-01 19:06:03 +01:00
|
|
|
|
|
|
|
connection extracon;
|
|
|
|
--reap
|
2020-10-03 00:24:53 +02:00
|
|
|
|
|
|
|
# Check if compression works OK
|
|
|
|
connect (comp_con,localhost,root,,,,,COMPRESS);
|
|
|
|
SELECT 1;
|
|
|
|
disconnect comp_con;
|
|
|
|
|