[cgiapp] Keep connection alive for request that takes long time to run

[Mike Tonks]

I use something similar in a file upload application.

After the file is posted to the web server, we transfer it to another
machine (server b) for post processing.  This can take from say 20
seconds up to a few minutes or more.

To keep the user happy I created an ajax routine in the browser that
polls the web server every 5 seconds or so for status updates.

I was nervous about this idea initially but it turns out to work
really well.  Server b now send various status notifications back to
the web server during the process and so we can display real time
progress to the user, as well as error notifications and so on.

The javascript handler can also react to the 'completed' stage and do
something e.g. download the results to the user when they are ready,
redirect to a new page, etc.

mike



On 12 February 2010 15:58, Mark Stosberg <mark at summersault.com> wrote:
> On Wed, 10 Feb 2010 10:38:00 -0500
> "Shao, David (NIH/NLM/NCBI) [C]" <shaod at ncbi.nlm.nih.gov> wrote:
>
>> Hi,
>>
>> I use CGI::Application for my web app. The app sometimes takes longer
>> to run than the timeout limit set by the apache server, which results
>> in a 'Bad Gateway' page at user side. My web admin suggested I need to
>> implement something similar to 'heartbeat' to keep the connection
>> alive. My interpretation to this is, while my app is running, it needs
>> to send a 'keepalive' packet to the client in short intervals (i.e.
>> shorter than the timeout limit), to prevent the server from dropping
>> the connection. I am fairly new to CGI::Application, and my questions
>> are if this feature already exists (but I can't find it in
>> documentation), or if it is not, is it possible to implement using
>> CGI::Application?
>
> Michael Peters is right that the ::Stream plugin concepts may be helpful
> here.
>
> I will offer an additional perspective which might be helpful. I had a
> long running report which was timing out. Because we knew the report
> took a long time, it was already designed to e-mail the report when it
> was done, rather than providing a synchronous response.
>
> This turned out to a great use for AJAX. We used AJAX to start
> the long-running report, and then immediately returned a result back
> to the screen indicating that the report would eventually arrive by
> e-mail.
>
>    Mark
>
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>