The script behind the request does the following:
- delete some files
- copy files from dir A to dir B
- read some data from a database and generates some XML-files
(i.e. a basic "publish" procedure)
The problem isn't the script itself, nor the server. I know this,
because the same code is being used on the same server for other
instances of this application.
Take this view-point, to keep your sanity:
The script is buggy, always has been buggy, but is only now exhibiting
noticable behaviour of the bug.
Which is painful, but better than the Voodoo of a script that is
"fine" except sometimes it's not.
The script has most definetly always been buggy. The only reason why we
weren't seeing this behaviour before, is because none of our other
customers which are using this app have as many pictures as the
"problem"-customer... Which is really frustrating, because I can't tell
him "Hey, you should use less photos in your website" (wish I could,
though :-p)
The only difference between the problem-app and the other apps is that
the problem app has:
A) a lot more files needing to be copied (number of files and size)
B) a lot more (stale) records in the DB
Do stale files correspond to the files getting deleted?...
If not, this is coming out of left field and you're not telling us
enough :-)
There are files on the server, which don't have a corresponding record
in the DB,
and there are records in the DB, which don't have a corresponding file
on the server.
However, after manually synchronising the 2 (files and records), the
problem still occurs, so that isn't it :-(
Another strange thing is, that when I try to view the source code of
the
blank page, my browser asks me if I want to send the request again :-(
Check the expiration headers -- If the browser thinks it's out of
date, then it will reload to "View Source", in some browsers.
Also, if the script terminated and Apache sent a non-200 return code,
then the browser "knows" it never got the real page, and may be trying
to help you by getting the true page when you do "View Source" I
think switching browsers may actually help this somewhat, as they
behave differently in these boundary conditions.
I took your advice and installed the firefox plug-in. Only header-info
I got from my blank page is "Status: ok - 200", nothing else (maybe I
should mention again, that at this moment, the script is still running...).
In the rare cases that the "publish" procedure does return the correct
result-page, the headers look quite different (i.e. a lot more
information than just the status)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
