0

I have a simple web-page (PHP, JS and HTML) that is displayed to illustrate that a computation is in process. This computation is triggered by a pure JavaScript AJAX-request of a PHP-script doing the actual computations. For details, please see here

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).

Letting the JavaScript with the AJAX-request display the request.status upon successfull return, surprisingly when I hit "Esc" in the browser window after the sleep is over, I also get the status "200" displayed but not automatically as it should do it.

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.

Best,

Shadow

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 not 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.

Community
  • 1
  • 1
Shadow
  • 1,042
  • 2
  • 15
  • 23
  • I found out that a "timeout" can be prevented, when the requested PHP-script actually "returns" some information, e.g. by echo("."). Of course, this only works, when one is able to return something repeatedly and the time between those return-moments is shorter than the 900 seconds. Naturally, this clutters the responseText of the AJAX-request so it is usable as a workaround but not necessarily the best solution... – Shadow Oct 01 '11 at 13:22

1 Answers1

0

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.

  • execute.php kicks off your background job on the server, and immediately returns.
  • Another script/URL (lets call it status.php) is available to check the progress of the task execute.php is performing.
    • 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.

More details on an approach similar to this: http://billhiggins.us/blog/2011/04/27/resty-long-ops

I hope this help give you some design ideas to address your problem!

Chris Cherry
  • 28,118
  • 6
  • 68
  • 71