| Bug #14057 | mysql_ping() handles TCP and UNIX socket connections in different ways | ||
|---|---|---|---|
| Submitted: | 16 Oct 2005 11:20 | Modified: | 27 Feb 2006 19:56 |
| Reporter: | Gleb Paharenko | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | 4.1.14, 4.1.16-BK | OS: | Linux (Linux (Fedora 4)) |
| Assigned to: | Magnus Blåudd | CPU Architecture: | Any |
[16 Oct 2005 11:20]
Gleb Paharenko
[16 Oct 2005 12:16]
Valeriy Kravchuk
Thank you for a problem report. It is easily repeatable. I was able to repeat the behaviour you described on latest 4.1.16-BK. The program built from 14057.c (will attach the file), gave me the following: Begin MySQL is up and running Restart MySQL and hit enter (reconnect: 1)... Result of ping: 1 Error: Lost connection to MySQL server during query Ping 2 Ok! Ping 3 Ok! with 127.0.0.1, and three 'Ok!' when working through socket (with localhost). But I do not understand, why is it a bug. According to the documentation (http://dev.mysql.com/doc/refman/4.1/en/mysql-ping.html): "A non-zero return does not indicate whether the MySQL server itself is down; the connection might be broken for other reasons such as network problems." So, the server is working, and we just recconect to it by using mysql_ping(), but connection was really broken when we shutted down the server (I did it using "mysqladmin -uroot shuwdown". While socket file still exists even after shutting down the server. I think, it is at most a documentation request, the small difference in behaviour that should be described with a simple example like yours. But not a bug. What do you think?
[16 Oct 2005 12:17]
Valeriy Kravchuk
Test case as a separate file.
Attachment: 14057.c (text/x-csrc), 991 bytes.
[16 Oct 2005 13:36]
Lefteris Tsintjelis
This is intresting, the documentation indeed mentions that mysql_ping indicates "Zero if the connection to the server is alive" and not that "zero if the server is alive", as I *naturally expected* also, so it is kind of tricky this one. I would expect the same behavior with Unix sockets or TCP sockets though. By restarting the server the connection breaks so I guess the first ping restores that broken connection and therefor returns with a non zero value since the connection was not alive at that moment. However, since reconnect was set, I would *very naturally expect* to try and reconnect first and then return with a 0 value if everything is OK. This would definetly make much more sence and make mysql_ping () much easier to use, instead of now making an extra mysql_ping () again to see if the first one restored the connection or not and it would definetly save some unessasary timeouts in case the server remains down.
[16 Oct 2005 16:08]
Gleb Paharenko
Hi! This makes sence. mysql_ping reports that connection is broken and then tries to reconnect again. Now, I agree that mysql_ping should report about the broken connection, in case we in the middle of some transaction (after reconnection we potentially lose table locks, user variables, session variables ). But this should be reported when we're using a Unix socket as well. So TCP part is working fine, but the Unix socket part could produce problems. And ,all in all, the different behavior should be ment in the documentation.
[17 Oct 2005 7:55]
Sergei Golubchik
This looks like a duplicate of http://bugs.mysql.com/bug.php?id=2845 Though mysql_ping can have a workaround for this - unlike mysql_query(), ping packet is always safe to send again, so mysql_ping can reconnect where mysql_query cannot.
[19 Oct 2005 6:07]
Lefteris Tsintjelis
I think there may be another issue with the timeouts here. In case the connection is completly lost and there is no response whatsoever from the server then mysql_ping must wait for 60 secs before it exits. If the connection was broken during a query, which is most likely and the time such a broken connection will be detected, then that is another 60 secs before we get an error and if we want to make sure that the connection is down and send a second ping then the total goes up to 3 minutes minimum before we can safely tell that the connection is broken. The default timing cost for all this is pretty high.
[9 Feb 2006 13:20]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/2362
[9 Feb 2006 14:18]
Magnus Blåudd
This is related to bug#15348
[16 Feb 2006 12:45]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/2727
[24 Feb 2006 8:10]
Magnus Blåudd
Pushed a fix to 5.0.19 and 5.1.8 that makes 'mysql_ping' retry if "reconnect" flag is set and it get error CR_SERVER_LOST in the first attempt to ping the server.
[27 Feb 2006 19:56]
Mike Hillyer
Documented in 5.0.19 and 5.1.8 changelogs:
<listitem>
<para>
The <function>mysql_ping</function> function will now retry
if the <literal>reconnect</literal>
flag is set and error <literal>CR_SERVER_LOST</literal> is
encountered during the first attempt to ping the
server. (Bug #14057)
</para>
</listitem>
[1 Mar 2006 15:36]
Armin Schöffmann
Seems to be connected with bug http://bugs.mysql.com/bug.php?id=927/
[4 Mar 2006 16:06]
Armin Schöffmann
typo: http://bugs.mysql.com/bug.php?id=9271/
