ID: 26608
Comment by: j dot howitt at mgn dot co dot uk
Reported By: gemery at bmihs dot co dot uk
Status: Assigned
Bug Type: Informix related
Operating System: RedHat Linux 8
PHP Version: 4.3.3
Assigned To: nobbie
New Comment:
Does anyone know when this bug may be fixed, Our our web site is
hitting this issue and soon will be put under a much greater load.As we
have already seen this bug appearing we are expecting it to cause us
hugh problems.
gemery at bmihs dot co dot uk wrote that apache 2 fixes this problem.
We are currently stress testing this, looking good so far, but from the
intro manual(installation guide) on the php site it says not to use php
on apache2 in a production environment. Does anyone know what issues
may be experienced by doing this?
Previous Comments:
------------------------------------------------------------------------
[2004-04-15 20:34:11] gemery at bmihs dot co dot uk
By the way, if you know anyone that has suffered this problem, get them
to vote on it. Maybe it'll get bumped up the priority list :-/
------------------------------------------------------------------------
[2004-04-15 20:29:00] 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-04-14 13:04:30] p_lc at voila dot fr
Same problem for us after Php4 migration two weeks ago.
Last version of PHP4, last version of Informix sdk.
And same problems in a critical application.
Even the rotation of informix users described in #14254 didn't changed
anything.
Strange, though, because we didn't saw anything similar in php3. Shall
we downgrade our server ?
Thank you for your help.
------------------------------------------------------------------------
[2004-04-13 09:35:36] cass at surek dot com dot br
We're running into the same problem here, but
unfortunatelly we don't have an option of switching to
another database as the other fellow did.
Can we expect anything regarding this matter?
------------------------------------------------------------------------
[2004-02-09 05:43:33] gemery at bmihs dot co dot uk
I'm afraid that due to excessive downtime we've been forced to move
away from php for the next version of our casetracking software :( The
boss pulled the plug and insisted we move to jsps instead. A sad day.
Thanks for a great product (apart from the unfortunate Informix issue).
Maybe if we change db we might move back to php.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/26608
--
Edit this bug report at http://bugs.php.net/?id=26608&edit=1
