[CONC-24] mysql_real_query() does not automatically reconnect Created: 2013-04-24  Updated: 2013-06-09  Resolved: 2013-04-25

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

Type: Bug Priority: Major
Reporter: Janani SriGuha Assignee: Georg Richter
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows 7/8, Using SQLyog and Mariadb C Client



 Description   

When executing queries on the server, if the client gets disconnected, we get the error "MySQL server gone away". After this even when the server is connected/restarted, the client still does not attempt to reconnect to the server. This does not happen in MySQL 5.5



 Comments   
Comment by Elena Stepanova [ 2013-04-24 ]

Hi,

Do you mean it doesn't happen with MySQL 5.5 server, or MySQL C client?
Also, do you happen to have a ready-to-use test case?

Thanks

Comment by Janani SriGuha [ 2013-04-24 ]

Hi,

I meant the MySQL C Client.

This happens about 40-50% of the time when the server is stopped or the connection is disconnected while a query or set of queries are executing, and every time we get the error MySQL server has gone away (2006).

Comment by Elena Stepanova [ 2013-04-24 ]

Hi Georg,

I didn't try it, as I suppose you'll be able to comment on it (or see what the reason of the problem is) right away.

Comment by Georg Richter [ 2013-04-25 ]

Fixed in revision 54.

Comment by Janani SriGuha [ 2013-04-30 ]

Hi,

This is still not fixed.

For a test case, you can download the community test build, here - http://www.webyog.com/downloads/betas/not_released/SQLyog-11.1.1-0.x86Community.exe
which is a test build using the MariaDB connector.
The latest GA of community can be downloaded from - http://sqlyog.googlecode.com/files/SQLyog-11.1.1-0.x86Community.exe

To reproduce:
Keep the table data tab open.
Open a few tables by selecting them in the Object Browser.
Stop the server.
Select any table in the Object Browser. - You will get an error "Could not connect to ..."
Start the server.
Select a few tables from the Object Browser. - they will load
Stop the server.
Select any table in the Object Browser. - You will get an error "MySQL server has gone away"
Start the server - click on any table in the object browser - You will still get an error "MySQL server has gone away"

Sometimes, the server has to be restarted 3-4 times to get this case. However this does not happen when using the MySQL connector. We never get the error "MySQL server has gone away" in this case.

We are using the mariadbclient library.

Let me know if you require any other details.

Comment by Janani SriGuha [ 2013-05-09 ]

Any progress regarding this?

Comment by Georg Richter [ 2013-05-09 ]

There was an additional bug in mysql_reconnect: The reconnect flag for the new connection wasn't set properly. This was fixed in rev. 58

Comment by Georg Richter [ 2013-05-09 ]

Am Donnerstag, den 09.05.2013, 09:37 +0300 schrieb Janani SriGuha

Hi,

sorry for the delay, we had (and have today also) some public holidays.

I was finally able to compile SqlYog with Visual Studio 2012 (for this I
had to change WINVER to 501 otherwise GetProcessID is unknown).

Also I had to fix CONC-9 (removing winsock.h) before.

I did some debugging sessions and think I found the reason: The first
reconnect attempt will always connect, while subsequent calls will fail,
since in mysql_reconnect we don't set the reconnect flag for the new
connection.

I just pushed the fixes with revision 58.

Thank you for your patience and for your help!

Kind regards

/Georg

(JIRA):

Comment by Janani SriGuha [ 2013-05-31 ]

Hi,

We are getting the same issue in a different case. When we insert data which is greater than the size of max_allowed_packet we get the "MySQL server gone away" error (2006). After this, executing any query fails to reconnect to the server.

Regards,
Janani

Comment by Vishal PR [ 2013-06-05 ]

Regarding above issue reported by Janani,

Source file: net.c
Function: net_clear

The function *net_check_if_data_available* tries to *select* the socket to determine whether its readable and *vio_read* calls *recv* to read the data. The problem here is, its not a must that *recv* will have some data even if *select* is successful. For example if the socket is not properly shutdown. In such situation *recv* will return -1 instead of 0. Since the return type is casted to size_t, which is an unsigned type and the condition check is only for non-zero, it iterates infinitely.

A simple patch would be to check the return value from *vio_read* against -1. But I just want to make sure that I didn't overlook anything there.

Comment by Georg Richter [ 2013-06-09 ]

Hi,

afaik this was already fixed in rev. 64. Could you please test against latest rev?

Thanks!

/Georg

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