ID: 14254 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Informix related Operating System: Solaris 8 PHP Version: 4.0.6 New Comment:
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 Previous Comments: ------------------------------------------------------------------------ [2001-11-27 12:36:25] [EMAIL PROTECTED] 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 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
