Referring to Bug #14254.

I can give some background clues which might help in resolving the intermittent SQLCODE=-439 error faster.
I support the php scripts for the same server which Cedric supports. We have noted that our client has increased their volume of data and traffic to the site dramatically since their intranet's inception over a year ago.

They're still using php3 (we're trying to convince them to pay us to convert their scripts to php4, but presently can't guarantee this would resolve the problem since it's still being reported by others using php4).

The effect seen is a refusal to connect to informix, caused by a peak in traffic. It's not something which is easily duplicated in a test environment, and is a mercurial problem in that as soon as it occurs, it often dissappears again as suddenly. We've seen it occur regularly for up to 40 minutes and then go away for several days.

Recently the complaint has been that some scripts simply return an empty page. On investigation this week I discovered these scripts were building massive arrays while remaining connected to informix, and apparently exceeding maximum script memory. It happens within 4-5 seconds so can't be the result of a timeout.

I suspect this is giving rise to accumulated garbage somewhere or leaving locks in the database and has a serious effect on subsequent attempts to connect to informix, which (sometimes) return SQLCODE=-439 error codes from ifx_connect().

We've tried using both ifx_connect and ifx_pconnect for the scripts, but this makes no apparent difference, just as increasing connection limits has failed to.

I've since optimised some of the offending scripts and this seems to alleviate the problem in the short-term, but a huge overhaul of the methods used is overdue but cannot be done so quickly, given the complexity of the intranet.

We'd like a resolution of the problem as soon as possible, even with scripts timing out or exceeding memory limits. I see you've recently improved the memory threading, and wonder if this could finally crack this long-standing problem?
Alan Frostick