[CONC-285] mysql_real_query takes time to return, if mysql server is disconnected from the network Created: 2017-10-03  Updated: 2017-10-06  Resolved: 2017-10-06

Status: Closed
Project: MariaDB Connector/C
Component/s: None
Affects Version/s: 2.3.3
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Sandhya Sriraj Assignee: Georg Richter
Resolution: Not a Bug Votes: 0
Labels: None
Environment:

Linux

Attachments: File mysqlsample.cpp    

 Description   

When executing a query using mysql_real_query(), if the machine on which the MySQL server is running is disconnected from the network, then it takes a lot of time for mysql_real_query() to return back, ~ 20 mins.

I am attaching the sample program here. The sample program uses the persistent connection and executes the query after every 1 minute.

Command to compile:
g++ -o mysqlsample mysqlsample.cpp -lmariadbclient -lpthread -lssl -lcrypto -L./lib -I./mysql -ldl

Command to run:
./mysqlsample

MariaDB C client library version: 2.3.3

Test case:
Disable the network after the query execution and then the next query execution will take ~20mins to return.

 Comments   
Comment by Georg Richter [ 2017-10-06 ]

MariaDB Connector/C (and also MySQL Connector/C) uses SO_KEEPALIVE socket option, so it depends on your kernel configuration (tcp_keepalive) how long it will take until read will fail.

If you want to detect timeout earlier, set the read timeout value before connecting to the server:

unsigned int read_timeout= 20; /* 20 secs */
 
mysql_option(mysql, MYSQL_OPT_READ_TIMEOUT, (void *)&read_timeout);

Comment by Sandhya Sriraj [ 2017-10-06 ]

With this option, mysql_query returns error "Lost connection to MySQL server during query" for every query which takes more than 20 seconds(read timeout value is 20 seconds). It should return immediately only if network is not available/ server is not running.

Comment by Georg Richter [ 2017-10-06 ]

See section 2.8 from the socket FAQ: "Why does it take so long to detect that the peer died?"

Generated at Thu Feb 08 03:04:13 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.