[MDEV-20845] Connect with MySQL table type times out when results don't start within 40 seconds Created: 2019-10-16 Updated: 2019-11-16 Resolved: 2019-10-31 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - Connect |
| Affects Version/s: | 10.3.18 |
| Fix Version/s: | 10.2.28, 10.1.42, 10.3.19, 10.4.9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Matthew Collins | Assignee: | Olivier Bertrand |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
CentOS7 |
||
| Description |
|
I've defined a Connect table as the mysql type with a srcdef that is a group by statement that takes about 2 minutes to start returning rows. Here is an abbreviated example:
When I try selecting anything from the connect table, after 40 second in my client I get: `MySQL said: Got timeout reading communication packets` I've set the net_read_timeout system variable in my.cnf to 3600 with no effect. I've also set OS and my.cnf level TCP keepalive values. Tables with srcdefs that take a long time to complete but start returning rows immediately work great. I found in the source myconn.cpp file in the MYSQLC::Open function a line that appears to fix the connection read timeout to 20 seconds:
Is this read timeout in the Connect mysql client what is causing this issue? Is there a reason it was hard coded to 20 seconds instead of, if I'm following the code, being allow to use the net_read_timeout system variable? |
| Comments |
| Comment by Matthew Collins [ 2019-10-21 ] |
|
I rebuilt MariaDB with the `mysql_options(m_DB, MYSQL_OPT_READ_TIMEOUT, &nrt);` line commented out and it now respects the net_read_timeout variable. So far it's happy to wait 15-20 minutes for the first rows to come back. Is there a reason why this was originally set to a fixed value? |
| Comment by Olivier Bertrand [ 2019-10-28 ] |
|
Hmmm... that was probably copied from some legacy code. Besides, all three lines at this address could probably be commented out. Alternatively, the cto and nrt values could be made parameters of the CREATE TABLE statement. What do you think would be the best solution? |
| Comment by Matthew Collins [ 2019-10-30 ] |
|
I personally don't have a use case for the Connect connection timeouts to be different from the rest of the places that net_read_timeout etc are used. I think it is definitely best to remove the fixed nrt and cto values so the behavior here is consistent with everything else. If you wanted to add new flags to allow overriding the net_*_timeout system variables in the CREATE TABLE, I could see how that might be useful. However, it looks like no one's had my issue with the current code's timeout in the last few years so I don't know how much use it would get. |
| Comment by Olivier Bertrand [ 2019-10-30 ] |
|
Ok, I'll just comment them out. BTW this is how FEDERATEDX works. |
| Comment by Olivier Bertrand [ 2019-10-31 ] |
|
Update fixed version numbers |