Mantis - Quercus
Viewing Issue Advanced Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2128 major always 10-29-07 20:04 10-30-07 12:13
Reporter: koreth Platform:  
Assigned To: ferg OS:  
Priority: normal OS Version:  
Status: closed Product Version: 3.1.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 3.1.4  
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
Attached Files:

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.