0002128: mysql_query() doesn't report connection loss to application - Mantis

Mantis Bugtracker

Viewing Issue Advanced Details [ Jump to Notes ]

[ View Simple ] [ Issue History ] [ Print ]

ID

Category

Severity

Reproducibility

Date Submitted

Last Update

0002128

[Quercus]

major

always

10-29-07 20:04

10-30-07 12:13

Reporter

koreth

View Status

public

Assigned To

ferg

Priority

normal

Resolution

fixed

Platform

Status

closed

OS

Projection

none

OS Version

ETA

none

Fixed in Version

3.1.4

Product Version

3.1.4

Product Build

Summary

0002128: mysql_query() doesn't report connection loss to application

Description

Configure a MySQL server to disconnect after 15 seconds of idle time. Then:

<?php
$conn = mysql_connect('mysql_host', 'user', 'password');
if ($conn)
  print "connected\n";
else
  print "connect error\n";
$ret = mysql_query("select 1");
if ($ret)
  print "query ok\n";
else
  print "query error\n";
sleep(20); // so the db breaks the connection
$ret = mysql_query("select 1");
if ($ret)
  print "query ok\n";
else
  print "query error\n";

Vanilla PHP prints:
connected
query ok
query error

Quercus prints:
connected
query ok
query ok

In other words, the error condition (which is definitely detected; a couple hundred lines of exception stack traces spew into the log) is not reported back to the client.

Steps To Reproduce

Additional Information

Relationships

Notes
(0002413) koreth 10-29-07 20:07	I wish I'd discovered this a year ago. This is probably the 0000001 reason why our app falls flat on its face under Quercus; we have code to deal with database reconnection (since it can happen to long-running vanilla PHP scripts too) but that code is triggered by mysql_query() failing and returning an appropriate error code from mysql_errno() (namely, errors 2013 or 2006). Right now our app is sitting there constantly trying to do more queries on the closed connections, which generates literally megabytes of spewing exception log traces for each page request.

(0002414) ferg 10-30-07 12:13	php/141l Quercus was relying on the getErrorCode() from the SQLException to determine the response. In the case of a connection failure, the mysql driver was returning 0 from getErrorCode(), which caused Quercus to return success. The Quercus behavior is now changed, so any SQLException will return an error response no matter what the getErrorCode() returns. If there is a 0 getErrorCode(), but there is an error, mysql_errno() will return 2006. I'm not sure this is the proper behavior, though.

Issue History
Date Modified	Username	Field	Change
10-29-07 20:04	koreth	New Issue
10-29-07 20:07	koreth	Note Added: 0002413
10-30-07 12:13	ferg	Note Added: 0002414
10-30-07 12:13	ferg	Assigned To	=> ferg
10-30-07 12:13	ferg	Status	new => closed
10-30-07 12:13	ferg	Resolution	open => fixed
10-30-07 12:13	ferg	Fixed in Version	=> 3.1.4

Mantis 1.0.0rc3[^]

Copyright © 2000 - 2005 Mantis Group

32 total queries executed.
28 unique queries executed.