|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #26608 Sporadic -439 errors on ifx_connect()
Submitted: 2003-12-12 12:55 UTC Modified: 2005-12-21 21:34 UTC
Avg. Score:4.8 ± 0.4
Reproduced:25 of 25 (100.0%)
Same Version:11 (44.0%)
Same OS:8 (32.0%)
From: gemery at bmihs dot co dot uk Assigned: nobbie (profile)
Status: Wont fix Package: Informix related
PHP Version: 5.*, 4.* OS: RedHat Linux 8
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2003-12-12 12:55 UTC] gemery at bmihs dot co dot uk
This problem has been around for quite some time.

The system will run fine for some time, then will suddenly start to throw these errors:

 [error] PHP Warning:  ifx_connect(): E [SQLSTATE=IX 000  SQLCODE=-439] in /var/www/html/casetrack/login.php on line 60, and
 [error] PHP Warning:  ifx_connect(): E [SQLSTATE=IX 000  SQLCODE=-439] in /var/www/html/appointments/functions.php on line 41

for some time. The system will eventually settle down again, and a restart of apache will always sort the problem out.

This is the description of that error from informix:

-439    Database server is currently processing an SQL task.
You attempted to call an SQL routine or attempted to execute an SQL statement within a signal handling function/routine or a callback function/procedure. Use only the sqldone() and sqlbreak() library functions inside your IBM Informix ESQL/C callback function. Use only the ECO-SQD and ECO-SQB library routines inside your ESQL/COBOL callback procedure. In addition, if you want to unregister your callback function in IBM Informix ESQL/C, you can invoke the sqlbreakcallback() callback registration function within your callback procedure. If you want to unregister your callback procedure in ESQL/COBOL, you can invoke the ECO-SQBCB callback registration routine within your callback

I'm running php with this configure:
 './configure' '--with-informix=/opt/informix' '--with-apxs' '--prefix=/opt/php' '--enable-track-vars' '--enable-magic-quotes'

against apache 1.3.23

IDS 7.31, ESQL/C version 9.5

Reproduce code:
I'm afraid I can't reproduce this without running our live system.
The best I can come up with is:

$connection = ifx_connect($db,$user,$pass);

Expected result:
Successful connection

Actual result:
[error] PHP Warning:  ifx_connect(): E [SQLSTATE=IX 000  SQLCODE=-439] in blah.php on line 1


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-12-14 20:37 UTC]
According to bug #14254, the newer informix sdk should fix this.

 [2003-12-17 09:57 UTC] gemery at bmihs dot co dot uk
OK.. Having the installed the new sdk and the snapshot (as suggested), the system ran fine for two days.
On the third day, these three errors occurred:

[error] PHP Warning:  ifx_query(): Set connection connec83 fails (E [SQLSTATE=IX 000  SQLCODE=-439]) in /var/www/html/casetrack/searchresult.php on line 0
[error] PHP Warning:  ifx_query(): Set connection connec80 fails (E [SQLSTATE=IX 000  SQLCODE=-439]) in /var/www/html/casetrack/searchresult.php on line 0
[error] PHP Warning:  ifx_query(): Set connection connec1 fails (E [SQLSTATE=IX 000  SQLCODE=-439]) in /var/www/html/casetrack/searchresult.php on line 0

After this, any attempt to use ifx_connect() resulted in this error:

[error] PHP Warning:  ifx_connect(): E [SQLSTATE=IX 000  SQLCODE=-439] in /var/www/html/casetrack/login.php on line 60

A restart of apache seemed to resolve the issue temporarily, but the problem recurs after a (random) amount of time.

Any help/suggestions would be appreciated as the new sdk doesn't seem to solve the issue.
 [2004-04-15 20:29 UTC] gemery at bmihs dot co dot uk
OK... Some new information:

I got in contact with Cornelius, the maintainer of the ifx code. He came up with the following (which is a work in progress):

-439 error:Description:        Each Apache Thread can only have 1 active connection to an informix database, after a -439 occurance.         o ifx_close() doesn't close the database connection, possibly leaving it available for other requests           - Fixed in PHP-4.3.4 (after RC1)         o ifx_close() can't close connections which produced -439 errors           - Looks like a bug (or feature) in the ESQL/C or IDS Engine, or incorrect thread usageReproduce bug:        o in httpd.conf, set MaxRequestsPerChild to 1        o access a php script which runs a massive query        o you'll keep getting -439 errors        =======================================TEMPORARY FIX=======================================Because the -439 error causes problems for Apache/PHP to reconnect in each thread, the thread should be closed often to kill the conection which is the problem.This doesn't prevent the problem, but makes it occur less, and not affect as many users when it does.In httpd.conf: o Set MaxRequestsPerChild to a low number (approx: the minimum number of possible connections in a request to your site, maybe times 3) o Set MaxKeepAliveRequests to a low number (see above)---------------------------------------=======================================HACKING INFO=======================================Things to check: o if ifx_close closes connection when -439 is encountered:    - NO    o why -439 is encountered on new connection attempt, in same apache thread after first -439:    - Possible Runaway process   - incorrect thread usage o if -439 is encountered immediately from same apache thread, different request, if first request has -439 set:    - YESThings to try: o ESQL/C thread safe stuff   - Didn't work for me o check error -451, from the release docsfrom /opt/informix/release/en_us/0333/ESQLCREL_9.1:92103   With arrary fetch enabled frontend doesn't recover from        -451 error but returns -439 error for all subsequent        operations           - Doubtedly, becuase the tests failed without blobs in sight

I have also upgraded our apache server to version 2 (2.0.49) and this seems to have made the problem go away entirely (possibly because it handles threading in a proper way - which seems to be the root cause of the 439 issue). 

Hope this helps. Some more news from the php devs would be appreciated though :)
 [2004-09-30 20:06 UTC] swinny23 at hotmail dot com
I had experienced the same thorn in my side for well over a year, and we just dealt with it by rebooting Apache every once in a while, but I think we have finally fixed the issue.  We switched to Apache 2 on Suse with PHP and all our 439 issues have went away.  So if you are using Apache 1.3 try changing to Apache 2 if you can.
 [2005-12-21 21:34 UTC]
The ext/informix is no longer supported. Since the IBM now  owns informix, you need to use and post any bugs of it there.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Jul 13 19:01:30 2024 UTC