Bug #14254 Updated: SQLERROR -439
ID: 14254
Updated by: sniper
Reported By: cedric.boudin@iconmedialab.com
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] 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
Thread (3 messages)