I have a working version of my web application that I am trying to upgrade at the moment, and I\'m running into the issue of having a task which
Normally you can't reply to the original request anymore since the context of that original request dissapears. Maybe, if you return from the request handler without replying and if somehow that doesn't kill the connection from the client and if you are somehow able to persist the handler object so that you can later restore it in another (internal) request and use the restored copy to reply from it to the original request... Kind of a long shot at best.
One option would be to split the operation into a sequence: - a 1st request starting the operation - subsequent one or more polling requests until the operation completes and the result is available
Another approach may be possible if the expensive operation is mainly executing on data available prior to when the operation is invoked. You could re-org the app logic so that partial results are computed as soon as the respective data becomes available, so that when the final operation is requested it only operates on pre-computed partial results. An analogy, if you want, would be Google search requests immediately receiving replies with data from pre-computed indexes instead of waiting for an actual web search to be performed.
Well, first, it's already bad to let users wait for 1 minute until page loads. In general, user-facing HTTP requests should take no more than 1 second. Those 60 seconds that GAE gives -- is already too generous, for critical situations.
I have several suggestions, but I don't know your application to say what you need:
lineups
value before user request it. For that you can utilize GAE Backend instances, which can run way longer than 60 seconds.makeLineups()
will do the trick.makeLineups()
. Once done, the task will take channel_id from Datastore and send there the computed value of lineups
.background_thread.BackgroundThread()
, the rest stays the same. UPDATE This will work better only with backend modules (basic or manual scaling, not automatic). On Frontend (default) modules, custom threads cannot outlive HTTP request, and hence also limited to 60s.Let me know if that helps.
I'm not familiar with GAE, but this is a fairly generic question, so I can give you some advice.
Your general idea is correct, so I'm just going to expand on it. The workflow could look like this:
setTimeout
or setInterval
you send requests with the task ID to the server (this is a separate endpoint). The server checks the status of the task, and returns the result if it's done (error if failed).