Avoiding client timeouts in a hellishly slow web app (and server timeouts)

[OwlHoot]

Executive Summary:

Need a simple technique to avoid client (and server) timeouts in a web app

Waffle:

I have a script that produces a report and, due to circumstances outside my control, can take up to several minutes to do it.

I incorporated this script in a simple web app, which requests the parameters in a FORM and then POSTs them to the server which runs the script and outputs a success or failure status - bog standard stuff.

However, the extreme slowness of this script means that users can end up getting "client timeouts", and I am seeking a simple way to avoid this.

In Firefox, one can type "about:config" in the address line, and increase the timeout by setting the following parameters:

   network.http.keep-alive                          true
   network.http.keep-alive.timeout                  300   <-- increase this

But I don't want to rely on the users having to make any manual tweaks like this, wondered if there is a simple Ajax solution. Before embarking on this though I wondered if Ajax wouldn't end up with exactly the same problem if an Ajax request exceeded this blasted client timeout value.

I realise the whole design isn't ideal - The user shouldn't have to wait several minutes, and the report script should be speeded up. So please don't bother wasting your breath by pointing this out. As I said, the script and the requirement is beyond my control.

But if anyone has any other ideas, along Ajax or Comet lines, but preferably without any plugins (such as Flash), I'd be very interested.

I mean it must be possible to evade these timeouts, or else how do tickertape and real-time update web apps work?

[Durbs]

What are you using server-side to generate the report? Java, .NET, PHP ????

Its there that you want to set the execution timeout.

[eek]

well ajax is simply javascript so you could have a static web page with a javascript routine called every x seconds to check the status of the request.

Then once the report is generated and the script returns success you redirect the page to the report.

I do have examples but don't have one on the box I'm typing this on (the joys of locked down machines and stupid security rules).

[OwlHoot]

What are you using server-side to generate the report? Java, .NET, PHP ????

Its there that you want to set the execution timeout.

It's a _client_ timeout, something that occurs in the browser if it doesn't get a server response within a certain time.

edit: Durbs, re your reply following this post, it _isn't_ the server returning the timeout (although I realize Apache also has a request timeout, which I'll worry about later). It's wretched _Firefox_ complaining it hasn't heard anything back within the "keep-alive" time. So in short you're barking up the wrong tree. But thanks anyway - I may have problems with server timeouts and proxy timeouts later!

[Durbs]

Then once the report is generated and the script returns success you redirect the page to the report.

But looking what he's posted above, it wont return a report, the server will return an execution timeout to the browser whether its ajax or not. Just sounds like the report is exceeding the default timeout period e.g 180 secs and is therefore returning an error. Increase the timeout and the browser will wait as long as you like.

[OwlHoot]

well ajax is simply javascript so you could have a static web page with a javascript routine called every x seconds to check the status of the request. ..

Sure, but what is to stop the initial Ajax request (to run the report) from timing out in the same way as a POST with no reply within the time?

Or will the periodic checks thereafter reset the client timeout timer each time?

I guess the checks would have to be actual HTTP requests themselves, and not just Javascript "is this flag set" checks, although there would be no way they could _actually_ check anything useful. But dummy requests, even to http : dontcare . com or something, would be fine as long as they reset the keep-alive client timer.

[dang65]

I don't know what the format of this report is, but it sounds like it might be a very large dataset. If it is, then the traditional method is to paginate the results so that the request is much smaller each time a call is made to the server. But that seems too obvious to have not been considered previously... although you do mention that the report generating code is out of your control.

[Spacecadet]

Store the results of the report elsewhere and then the page that the user is on simply polls the server to see if the results are available yet. When they do become available the user is informed and clicks a further link to retrieve the results.

You might want to do something so that if the server isn't getting "is it finished yet?" requests then it will cancel the job automatically.

[Sysman]

This s a problem I had 20 years ago with dumb terminals. Of course I could fix the timeout, but the real problem was that the user couldn't do anything else on their terminal until the job finished. My solution was to submit the report job to batch and send the user a message when it completed.

A similar approach seems appropriate here. In modern terms that could translate to sending the user an email either with the report attached or with a URL pointing to it.

This also deals with a PC/browser/network crash; the user won't be submitting the (presumably resource intensive) job multiple times simply because something went wrong at their end.

[FiveTimes]

make an async request and poll for a result file ?