for long run stuff, people are usually using job queue like gearman, theschwartz or minion etc.
you can send a ID back to app first, then init another request with that id to check if it's finished. Thanks On Wed, Mar 28, 2018 at 6:31 PM, PANG J. <pa...@uk2.net> wrote: > what the client I meant is mobile App. > mobile App gets the result from server via SDK. > in future we may move the computing task into App itself. > But currently they are running on server side. > > thanks. > > > On 2018/3/28 星期三 PM 6:11, André Warnier (tomcat) wrote: >> >> I believe that the timeout which Pang J. is mentioning, may be the >> browser-side timeout, which is fixed at the browser level at about 5 minutes >> or so. >> When a browser sends a request to a server, and it does receive /some/ >> response within the next +-5 minutes, then the browser will drop the >> connection to the server, and pop up a message saying "sorry, the server >> appears not to respond.." >> In other words, it is not a server timeout, it is a client timeout. >> The only way to avoid this, is to insure that the server sends at least >> /some/ temporary response to the client (*), regularly, so that this browser >> timeout does not occur. >> Unfortunately, that is a bit more complicated to set up, than just some >> parameter somewhere. >> But there must be plenty of past discussions of this issue already on the >> www, and solution guidelines. -- Fayland Lam // http://www.fayland.me/
