ID: 9852 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.1.1 New Comment:
Some further info on the problem: I applied the slowdown script after each query (in the simpleQuery method of PEAR's mssql driver) but I still got the occasional CGI Error (and it was awfully slow, too). I then applied the slowdown script at the start of each script, but still to no avail. What I did notice was that it did help the problem, but not eliminate it. My problem was still there when I refreshed my entire frameset (which caused 6 scripts to run mssql db commands simultaneously). Often 2 or 3 of these scripts failed with CGI errors. Previous Comments: ------------------------------------------------------------------------ [2002-05-28 08:30:12] [EMAIL PROTECTED] I tried the ISAPI module, but that died in *lots* of other ways - I get the impression I should stay with CGI :( I've since tried playing with the mssql parameters in php.ini (thought persistent connections may be the problem) with no success. I think I may try that slowdown script, but against all queries - it didn't work for me before the redirect - I don't always have a redirect :( Any other suggestions welcome... ------------------------------------------------------------------------ [2002-05-28 06:10:52] [EMAIL PROTECTED] I have the same problem, but I have some more interesting facts to add... I can reproduce it with mssql or odbc drivers, and intererstingly I can get it breaking without using a header redirect. I have an application that uses a frameset, and it appears that sometimes (2 out of 3 times) it will give me the CGI error in multiple frames, even though I've switched from header redirects to javascript redirects. The URL changes at the browser, and it's the target page that fails to load - not the page with the redirect code. I have also had it failing on another page that used the IIS custom error page functionality (i.e. replacing a 404 error with a nice custom page)...again, a "fast redirect" issue, just like the original bug reporter. I do believe it is a timing problem - for me it only fails on a fast dual-processor production server, but works fine on my slower single-processor development server. It also works fine if I shift the production server to a MySQL database. Note that I tried using the slowdown function above, but it didn't work for me - perhaps multiple simultaneous page loads from the frameset also breaks it? By the way, mine fails on version 4.2.1 (released May 2002), so obviously this little bug hasn't been caught for over a year. I read above that the ISAPI version doesn't seem to do it, so I'll look at implementing ISAPI for this job. However, that could mean that it's to do with the persistant database connection, as the ISAPI module remains loaded between page views. ------------------------------------------------------------------------ [2002-04-22 17:50:12] [EMAIL PROTECTED] It seems to be a timing problem (the PHP script outruns the IIS/MSSQL or something). I came up with a simple solution to this by inserting a short delay before every location header in my scripts. I successfully made the workaround by using a function from a user comment on the http://www.php.net/manual/en/function.usleep.php page The function was: ------------------------------ function usleepWindows($usec) { $start = gettimeofday(); do { $stop = gettimeofday(); $timePassed = 1000000 * ($stop['sec'] - $start['sec']) + $stop['usec'] - $start['usec']; } while($timePassed < $usec); } ------------------------------ Every header call should then look like this: ------------------------------ usleepWindows(200000); header("Location: http://www.myserver.dk/mypage.php";); exit; ------------------------------ /watson ------------------------------------------------------------------------ [2002-04-22 16:36:05] [EMAIL PROTECTED] I tried to use both a MySQL and a MSSQL database server on the same machine. When using the MySQL database there where no problem, and when using the MSSQL database the problem was there. So the problem seems to follow the combination of: IIS and MSSQL. I have seen this error on all the PHP versions that I tried, and that is: PHP 4.0.6, PHP 4.1.1 and PHP 4.1.2. I don't know if it's in any other PHP versions besides that. ------------------------------------------------------------------------ [2002-03-27 13:16:00] [EMAIL PROTECTED] I can reproduce the problem with a simple "bounce" page (used for measuring roundtrip times). With two active browser windows requesting the same page, I see this error repeat (apparently at random) on one out of 10-40 thousand requests. This is with PHP 4.1.2 on Windows 2000 Professional w/ IIS 5 and all the current updates from Windows Update. bounce.php ---------- <html> <head> <title>BOUNCE</title> <?php list($usec, $sec) = explode(" ",microtime()); $now = intval(1000*((float)$usec + (float)$sec)); $i = (isset($i) ? $i : 0); $n = (isset($n) ? $n : 10); $s = (isset($s) ? $s : 0); $r = (isset($r) ? $r : 0); ?> <?php if (0 == $i) { ?> <meta http-equiv="Refresh" content="0; URL=bounce.php?s=<?= $s ?>&r=<?= $r ?>&i=1&t=<?= $now ?>"> <?php } else if ($i < $n) { ?> <meta http-equiv="Refresh" content="0; URL=bounce.php?s=<?= $s ?>&r=<?= $r ?>&i=<?= 1 + $i ?>&t=<?= $t ?>"> <?php } else { ?> <?php $e = $now - $t; $r = $r + $n; $s = $s + $e; ?> <meta http-equiv="Refresh" content="3; URL=bounce.php?s=<?= $s ?>&r=<?= $r ?>"> <?php } ?> </head> <body> <?php if ($i < $n) { ?> <h1>BOUNCING</h1> <?php } else { ?> <h1>BOUNCE</h1> <table border=1> <tr><th>milliseconds</th><th>requests</th></tr> <tr><td><?= intval($e/$n) ?></td><td><?= $n ?></td><td>latest</td></tr> <tr><td><?= intval($s/$r) ?></td><td><?= $r ?></td><td>cumulative</td></tr> </table> <?php } ?> </body> </html> ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/9852 -- Edit this bug report at http://bugs.php.net/?id=9852&edit=1
