What the actual computation is, does not play a role, so for simplicity, it is just a sleep()-command.
When I execute the same code locally (browser calls website under localhost: linux, apache, php-mod) it works fine, independant of the sleep-time.
However, when I let it run on a different machine (not localhost, but also Linux, apache, php-mod), the PHP-script does run through (results are created), but the AJAX-request does not get any response, so there is no "onreadystatechange" if the sleep-time is >= 900 seconds. When sleep-time < 900 seconds it also works nicely and the AJAX-request is correctly terminated (readyState==4 and status==200).
The apache and php-configuration are more or less default and I verified the crucial options there already (max_execution_time etc.) but none seems to be valid here as they are either shorter (<1 min.) or bigger, e.g. for the garbage-collector (24 min.).
So I am absolutely confused what may cause this. I am thinking it might be network-related, although I didn't find any appropriate option in my router or so. Also no error is reported in the apache-logs or in PHP (error loggin to file).
In any case, I am hoping that you may have an idea how to circumvent this problem? Maybe some dummy-communication between client and server every 10 minutes or so might do the trick, but I don't have an idea how to best do something like this, especially letting this be transparent to the user and not interfering with the actual work of doing the computations/sleep.
P.S. The post that I am referencing is written by me, but seems to tramsit the idea that it might be related to some config-option, which seems <em>not</em> to be the case. This is why I am writing this post here, basically asking for a way to circumvent such an issue regardless of it's origin.Answer1:
I'm from the other post you mentioned!
Now that I know more about what you are trying to do: monitor a possibly long running server job, I can recommend something which should turn out a lot better, its not a direct answer to your question, but its a design consideration which includes by its nature a more suitable solution.
Basically, unlink the actions of "starting" the server side task, from monitoring its progress.<ul><li>execute.php kicks off your background job on the server, and immediately returns.</li> <li>Another script/URL (lets call it status.php) is available to check the progress of the task execute.php is performing. <ul><li>When status.php is requested, it won't return until it has something to report, UNLESS 30 seconds (or some other fixed) amount of time passes, at which point it returns a value that you know means "check again". Do this in a loop, and you can be notified immediately of when the background task has completed.</li> </ul></li> </ul>
More details on an approach similar to this: <a href="http://billhiggins.us/blog/2011/04/27/resty-long-ops" rel="nofollow">http://billhiggins.us/blog/2011/04/27/resty-long-ops</a>
I hope this help give you some design ideas to address your problem!