Hi all, Due to a long running action that was blocking all other users, I''m moving my production environment over to FastCGI. I knew I''d hit the timeout limit of FastCGI for this long running action (it''s a report generation)... and rather than increase the timeout I''d prefer to do the whole: "Please Wait... Generating Report" with periodic checks (ie: via Ajax).. then a redirect at the end. Given that this would be reasonably common practice.. has anyone already implemented this? Searching found nothing but I''m betting I''m about to reinvent the wheel here. Thanks in advance
Just to elaborate here: What I was thinking was some kind of filter that would run in parallel with an action. If it takes more than say: 5 seconds to render it would display a "Please Wait.." page that checks again with ajax. If no one has written it I''ll write it today as I''m in need of it and would rather not make some specific hack for the one place in my app that I expect long render times.. but I''d love to get some feedback on the best way and place to implement it.. On Sunday 29 May 2005 08:55, Luke Galea wrote:> Hi all, > > Due to a long running action that was blocking all other users, I''m moving > my production environment over to FastCGI. > > I knew I''d hit the timeout limit of FastCGI for this long running action > (it''s a report generation)... and rather than increase the timeout I''d > prefer to do the whole: "Please Wait... Generating Report" with periodic > checks (ie: via Ajax).. then a redirect at the end. > > Given that this would be reasonably common practice.. has anyone already > implemented this? Searching found nothing but I''m betting I''m about to > reinvent the wheel here. > > Thanks in advance > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
If your report generation takes more than a minute, you might consider using a polling script that runs periodically and generates reports, and use ajax to query the results of that script. This may seem over-complex, but sometimes it''s desirable to have these sorts of tasks separated from the web server process. If not, the recently updated Upload Progress patch from Sean Treadway may give you an idea as to how to something like this: http://sean.treadway.info/articles/2005/05/26/upload-progress-update Joshua Sierles On 5/30/05, Luke Galea <lgalea-vvW6YJTQFGvMohDmgNdYFA@public.gmane.org> wrote:> Just to elaborate here: > What I was thinking was some kind of filter that would run in parallel with an > action. If it takes more than say: 5 seconds to render it would display a > "Please Wait.." page that checks again with ajax. > > If no one has written it I''ll write it today as I''m in need of it and would > rather not make some specific hack for the one place in my app that I expect > long render times.. but I''d love to get some feedback on the best way and > place to implement it.. > > On Sunday 29 May 2005 08:55, Luke Galea wrote: > > Hi all, > > > > Due to a long running action that was blocking all other users, I''m moving > > my production environment over to FastCGI. > > > > I knew I''d hit the timeout limit of FastCGI for this long running action > > (it''s a report generation)... and rather than increase the timeout I''d > > prefer to do the whole: "Please Wait... Generating Report" with periodic > > checks (ie: via Ajax).. then a redirect at the end. > > > > Given that this would be reasonably common practice.. has anyone already > > implemented this? Searching found nothing but I''m betting I''m about to > > reinvent the wheel here. > > > > Thanks in advance > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Hmm.. not a bad idea.. I guess I could keep it "generalized" if I had a render queue table that stored a serialized version of the @params, along with the action and controller.... On Monday 30 May 2005 09:39, Joshua Sierles wrote:> If your report generation takes more than a minute, you might consider > using a polling script that runs periodically and generates reports, > and use ajax to query the results of that script. This may seem > over-complex, but sometimes it''s desirable to have these sorts of > tasks separated from the web server process. > > If not, the recently updated Upload Progress patch from Sean Treadway > may give you an idea as to how to something like this: > > http://sean.treadway.info/articles/2005/05/26/upload-progress-update > > Joshua Sierles > > On 5/30/05, Luke Galea <lgalea-vvW6YJTQFGvMohDmgNdYFA@public.gmane.org> wrote: > > Just to elaborate here: > > What I was thinking was some kind of filter that would run in parallel > > with an action. If it takes more than say: 5 seconds to render it would > > display a "Please Wait.." page that checks again with ajax. > > > > If no one has written it I''ll write it today as I''m in need of it and > > would rather not make some specific hack for the one place in my app that > > I expect long render times.. but I''d love to get some feedback on the > > best way and place to implement it.. > > > > On Sunday 29 May 2005 08:55, Luke Galea wrote: > > > Hi all, > > > > > > Due to a long running action that was blocking all other users, I''m > > > moving my production environment over to FastCGI. > > > > > > I knew I''d hit the timeout limit of FastCGI for this long running > > > action (it''s a report generation)... and rather than increase the > > > timeout I''d prefer to do the whole: "Please Wait... Generating Report" > > > with periodic checks (ie: via Ajax).. then a redirect at the end. > > > > > > Given that this would be reasonably common practice.. has anyone > > > already implemented this? Searching found nothing but I''m betting I''m > > > about to reinvent the wheel here. > > > > > > Thanks in advance > > > _______________________________________________ > > > Rails mailing list > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
An alternative I''m looking at as a quick fix is to just spawn a thread and email the report to the user upon completion. Is there any caveat''s I should be aware of in spawning a thread in the controller, doing a simple render_text but having a thread started that continues doing a render and email? On Monday 30 May 2005 09:45, Luke Galea wrote:> Hmm.. not a bad idea.. > > I guess I could keep it "generalized" if I had a render queue table that > stored a serialized version of the @params, along with the action and > controller.... > > On Monday 30 May 2005 09:39, Joshua Sierles wrote: > > If your report generation takes more than a minute, you might consider > > using a polling script that runs periodically and generates reports, > > and use ajax to query the results of that script. This may seem > > over-complex, but sometimes it''s desirable to have these sorts of > > tasks separated from the web server process. > > > > If not, the recently updated Upload Progress patch from Sean Treadway > > may give you an idea as to how to something like this: > > > > http://sean.treadway.info/articles/2005/05/26/upload-progress-update > > > > Joshua Sierles > > > > On 5/30/05, Luke Galea <lgalea-vvW6YJTQFGvMohDmgNdYFA@public.gmane.org> wrote: > > > Just to elaborate here: > > > What I was thinking was some kind of filter that would run in parallel > > > with an action. If it takes more than say: 5 seconds to render it would > > > display a "Please Wait.." page that checks again with ajax. > > > > > > If no one has written it I''ll write it today as I''m in need of it and > > > would rather not make some specific hack for the one place in my app > > > that I expect long render times.. but I''d love to get some feedback on > > > the best way and place to implement it.. > > > > > > On Sunday 29 May 2005 08:55, Luke Galea wrote: > > > > Hi all, > > > > > > > > Due to a long running action that was blocking all other users, I''m > > > > moving my production environment over to FastCGI. > > > > > > > > I knew I''d hit the timeout limit of FastCGI for this long running > > > > action (it''s a report generation)... and rather than increase the > > > > timeout I''d prefer to do the whole: "Please Wait... Generating > > > > Report" with periodic checks (ie: via Ajax).. then a redirect at the > > > > end. > > > > > > > > Given that this would be reasonably common practice.. has anyone > > > > already implemented this? Searching found nothing but I''m betting I''m > > > > about to reinvent the wheel here. > > > > > > > > Thanks in advance > > > > _______________________________________________ > > > > Rails mailing list > > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > _______________________________________________ > > > Rails mailing list > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On 31/05/2005, at 4:08 AM, Luke Galea wrote:> An alternative I''m looking at as a quick fix is to just spawn a thread > and > email the report to the user upon completion. > > Is there any caveat''s I should be aware of in spawning a thread in the > controller, doing a simple render_text but having a thread started that > continues doing a render and email?I went down the thread path, and I''m starting to wish I hadn''t... the FastCGI version that I have was being killed randomly (I tracked down the cause: fcgi process management) and I always have to worry about the process when restarting the webserver. Next time I touch the system I plan to move it into it''s own script, maybe look into talking to it with drb... Although, if your process only takes a few minutes, then by all means, try it out with a thread!It''s trivial to write. bodhi
Thanks for the tip Bodhi. It should be easy enough to go the threading route and later change it.. Did you find that the thread solution worked for both webrick and fastcgi? I''m running webrick for development and fastcgi for production.. I quickly tossed in the threading code and ran in development webrick but found the reponse wouldn''t get written until the thread finished (perhaps webrick is joining all threads??) I guess I''ll have to branch based on the environment and only thread in production.. irritating though! On Monday 30 May 2005 21:31, bodhi wrote:> On 31/05/2005, at 4:08 AM, Luke Galea wrote: > > An alternative I''m looking at as a quick fix is to just spawn a thread > > and > > email the report to the user upon completion. > > > > Is there any caveat''s I should be aware of in spawning a thread in the > > controller, doing a simple render_text but having a thread started that > > continues doing a render and email? > > I went down the thread path, and I''m starting to wish I hadn''t... the > FastCGI version that I have was being killed randomly (I tracked down > the cause: fcgi process management) and I always have to worry about > the process when restarting the webserver. Next time I touch the > system I plan to move it into it''s own script, maybe look into talking > to it with drb... > > Although, if your process only takes a few minutes, then by all means, > try it out with a thread!It''s trivial to write. > > bodhi > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails