|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2001-11-27 12:36 UTC] cedric dot boudin at iconmedialab dot 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 PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Tue Oct 28 16:00:01 2025 UTC |
Well, I see this problem every time I run my scripts. We are running: PHP 4.2.1 Apache 1.3.24 ESQL/C Version 9.51 Some of the Informix tables are large. Since I am seeing this consistently, I would really like to see a fix to this problem. My scripts are somewhat complicated. But I can reproduce the problem with a simple script. It contains: ----------------------------------------------------------- <?php // create connection $connection = ifx_connect("<deleted>", "<deleted>", "<deleted") or die("Couldn't create connection."); // create SQL statement $sql = "SELECT f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, f13, f14 FROM T1 where f1 < 500"; // execute SQL query and get result $sql_result = ifx_query($sql,$connection) or die("Couldn't execute query"); // format result in HTML table ifx_htmltbl_result($sql_result,"border=1"); // free resources and close connection ifx_free_result($sql_result); ifx_close($connection); ?> ----------------------------------------------------------- To reproduce this, I hit the refresh button on the browser before the page had downloaded. I tried switching it to pconnect and still got SQLCODE=-439 failures. Although the table is big, I think the load was light (I tried this on a Saturday afternoon.) Anyone that has questions, feel free to send them to me at pschmidt@naxs.net Best Regards, Paul Schmidt Action Web CreationsWell, we came up with a hack to work around this miserable bug. You can see our environment listed in the posting we made above. The following is our assessment of the problem and the work around solution: -------------------------------------------------------- ifx_connect call (from Informix CSDK) fails on repeated queries. The problem seems to be that it believes that the returned connection ID is already in use! The informix error follows: -439 Database server is currently processing an SQL task. You attempted to call an SQL routine or attempted to execute an SQL statement within a signal handling function/routine or a callback function/procedure. Use only the sqldone() and sqlbreak() library functions inside your INFORMIX-ESQL/C callback function. Use only the ECO-SQD and ECO-SQB library routines inside your ESQL/COBOL callback procedure. In addition, if you want to unregister your callback function in INFORMIX-ESQL/C, you can invoke the sqlbreakcallback() callback registration function within your callback procedure. If you want to unregister your callback procedure in ESQL/COBOL, you can invoke the ECO-SQBCB callback registration routine within your callback procedure. Found reports of a PHP bug that seems related (#14254). Bug goes back years, no fix reported. Just "make system faster". I found anohter related(?) bug (#18534 ifx_close() leaves open session) Docs on ifx_connect show the following: "In case a second call is made to ifx_connect() with the same arguments, no new link will be established, but instead, the link identifier of the already opened link will be returned." Theory is that ifx_close doesn't immediately close the connection. Since the parameters in ifx_connect are always the same (user, passwd and database), the next ifx_connect() tries to use the existing connection, and sometimes fails (busy, in process of closing, ???) Our fix: Try using "rotating users" - we set up 10 "bdtdb" users (bdtdb0-9), all with same uid/passwd on Solaris system. Use different one for each connect, the chance of colliding with an open/bad connections drops a lot (doesn't go awasy completely). Here's our code: // This is a hack to work around // the bug 439 (see Informix docs // - finderr 439) that relates to // PHP concurrency problems with // Informix. // In essence, we are recycling // usernames so that we can convince // Informix to issue a new resource id // for our connection, thus preventing // collisions. Note that collisions // could still occur, but it would be // much less likely. To make it even // less likely, use more user names. // This is the best we can do, // since no one here has the // time to debug the PHP/Informix modules. function getDBUserName() { global $HTTP_SESSION_VARS; $NUM_USERS = 9; $user_index = $HTTP_SESSION_VARS['user_index']; // First time in if (!$user_index && $user_index != 0) { // $user_index = rand (0,$NUM_USERS); // Random # between 0 and numusers // This doesn't work even if it is // seeded. Always starts on // same number. Go figure. $user_index = 0; } else { $user_index = $user_index + 1; if ($user_index > $NUM_USERS) $user_index = 0; }//else $HTTP_SESSION_VARS['user_index'] = $user_index; return ("bdtdb" . $user_index); }//getDBUserName() //----------------------- Defined Vars ------------- $db_userid = getDBUserName(); $db_password = "fish911"; $db_database = "www_bdat@ius_baydelta_tcp"; // ---- Then use these in your connection to db. // We are definitely not using persistent // connections. Tested this hard - could not make it break, even with heavy load. Prior to fix, even light loads would create error.