Bug #14254 Updated: SQLERROR -439

ID: 14254 Updated by: markonen@php.net Reported By: cedric.boudin@iconmedialab.com -Status: Open +Status: Closed Bug Type: Informix related Operating System: Solaris 8 PHP Version: 4.0.6 New Comment: Your problem seems to be a pure performance issue. Unfortunately these kinds of problems present themselves in a non-deterministic fashion, which makes the symptoms hard or impossible to debug. The cure, however, seems clear: upgrade to PHP 4.2, upgrade the hardware, install Zend Optimizer, buy Zend Cache -- anything to match your server resources with the increased load on your system. Based on your description of the scripts used, PHP 4 alone should bring a huge performance increase. Your client's possible unwillingness to pay for upgrades is quite simply *their problem*. Hang in there, iconites ;-) Previous Comments: ------------------------------------------------------------------------ [2002-05-25 09:13:10] alan.frostick@iconmedialab.com 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 ------------------------------------------------------------------------ [2001-11-28 07:26:16] cedric.boudin@iconmedialab.com a short script would not reproduce the conditions for recreating the failure. It happens when we have a lot of load and this with big scripts using lots of memory and sometimes timing out. If the timeout comes from the db connection being lost or vice versa is hard to say If we could isolate where in the php ifx interface callback functions are used we would be a step further in solving this. ------------------------------------------------------------------------ [2001-11-27 12:57:34] sniper@php.net Can you please add a short PHP script with which you can reproduce this ? Also, please try PHP 4.1.0 (to be released very soon now) as it has some improvements to the threading which might actually fix this problem. (it was mentioned as one possibility in that mail you pointed to in the archives) I don't have informix installed or any knowledge how to set it up either so you need to help us in this. And I don't have much time to spend on this either so please be patient. --Jani ------------------------------------------------------------------------ [2001-11-27 12:36:25] cedric.boudin@iconmedialab.com Similarly to Bugs 13459 and 8267 we do get error 439. on php 3.0.18 and 4.0.6 http://marc.theaimsgroup.com/?l=php-dev&m=97812975300057&w=2 we do have support from ifx. they are prepared to help us here qote from ifx support ---- I have received this case and I have looked through the case history. The situation appears to be as follows. Your network traffic has increased and that in turn brought about more timeout situations where an ESQL/C callback was used by your application (or by PHP). The -439 error indicates that unauthorized calls are included in that callback function. There are two ways to avoid getting the errors. 1. Tweak the system to increase performance to the point where the timeouts do not occur. 2. Fix the callback function code. Since you have indicated that you will not attempt number 1 we are left with number 2. Number 2 is the responsibility of the person that wrote the callback function, be that you or PHP. The only way that Informix can fix the problem is if the -439 is being given in error. At this time there is no indication that the -439 error is not correct but it is still a possibility. Unfortunately we cannot know whether or not the -439 error is erroneous or not until we know exactly how the callback function is being set up. So the next thing that must happen is that I get a small test case showing setting up a correct callback function that fails with this error. If you are writing the callback functions then we need to get PHP out of the picture and you need to provide me a very small ESQL/C test case that gives the same error. If the callback functions are contained in PHP then the only other option is to pursue an answer through Apache tech support and let them contact me when and if they find that the -439 is not correct. In that case they will be providing the test case. If PHP cannot be removed from the picture then you need to open a case with Apache as soon as possible. Given the nature of Apache this might not be a viable option and you may instead want to look at the PHP source yourself. -- end quote --- begin quote Both the -439 and the -25588 errors are occuring because of timeouts. Odds are that they are simply different symptoms of the same underlying problem and which error you get depends on timing of internal events. If you want to focus on performance tuning I can pass the case back to an engines engineer. This will only be brushing the problem under the carpet, however. If your application is not doing callbacks correctly then it will give this error any time that activity gets too high. Does your application provide the callback function or is that all built into PHP? -- end quote so now we have the chance to get rid of this annoying bug. I cnnot possibly plunge into the phpsourcecode to get the info the guy from ifx needs. If your are interested to get this thing sorted out this is the chance ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=14254&edit=1