Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0(EOL), 10.1(EOL)
-
None
-
10.1.9-2
Description
|
Test case |
--let $trial = 100
|
|
|
while ($trial)
|
{
|
--connect (con1,localhost,root,,)
|
--disconnect con1
|
--dec $trial
|
}
|
--echo # All done
|
On 10.0 commit aad8667f8a4e2a26652494b29ee6c12824865ac8 the test goes almost instantly:
Spent 0.126 of 13 seconds executing testcases
|
On 10.0 commit a453a280403faef3377db0441560c57b4ae1235b it takes much much longer:
Spent 100.209 of 118 seconds executing testcases
|
Also, the complete test run on win64-release2 seems to take twice as much as it used to, ~3:30 vs 1:40.
Attachments
Issue Links
- causes
-
-
- Closed
-
Activity
So, what could the fix be? Can we just tell the client to connect to IPv4 address, like --host=127.0.0.1 ?
There would improve the speed, in general case.
For example we could change fix_host() in lib/My/ConfigFactory.pm to return "127.0.0.1" rather than "localhost" . Connections that are done within tests itself, ánd reference localhost, like
connect(con1,localhost,root,,);
would still be somewhat slower. Maybe this is not a big deal.
Maybe adding --bind-address=* to the server options on Windows would help as well.
On the other hand, perhaps it is possible to fix mtr to ignore the warnings from MDEV-8083 (since those are not really errors), and let bind-address as default ?
Ignoring warnings from MDEV-8083 is kind of fine, but we need not to ignore them in ipv6 specific tests. Currently there's no way to enable a warning suppression globally and undo it for specific tests. But, of course, we can add it.
Specifying --bind-address=* on Windows, again, would be fine, but at the moment my.cnf files don't have per-os sections and mtr my.cnf templates are not per-os either. Still, we can have fix_bind() function that will return * for Windows and 127.0.0.1 otherwise. That should be easy to do.
This is a side-effect of the fix for
MDEV-8083MTR is broken on systems with IPv6 disabled https://github.com/MariaDB/server/commit/a453a280403faef3377db0441560c57b4ae1235bThe fix makes server to listen only on IPv4 by default, rather than IPv4 + IPv6
the client tries to connect to addresses returned by getaddrinfo() , in the order in which this function returns IP addresses. So, getaddrinfo gives 2 addresses for localhost, the IPv6 and IPv4, in this order. Prior to
MDEV-8083, server was listening on both IPv4 and IPv6, this the very first attempt to connect would succeed. After theMDEV-8083fix, attempt to connect to IPv6 address fails, and the failing attempt takes some time (long time to connect to non-existing address this might be Windows specific)