A few weeks ago I run in a similar problem trying to repetitively run a group of steps for a simple get operation without blocking the controller.
After receiving some advices from the #mojo irc channel folks I end up with a plugin that should be able to repeat a set of steps without block the controller several times, controlled by a flag that allows you to stop and finish the rendering. You can take a look at https://github.com/dmanto/Mojolicious-Plugin-RestartableDelay.git You should have a working postgresql installation, and a "test" named database that your username can access. Postgresql is used just as an example here, to have some query to retrieve several times before the controller finish the operation. It has some tests, you should be able to pass them. Important routes are: get /blocking/number-of-records-to-retrieve, and get /non-blocking/number-of-records-to-retrieve you should be able to run this two cases: $> ./pg_nb2.pl get /blocking/10000 and $> ./pg_nb2.pl get /non-blocking/10000 and you will note that the non-blocking version starts right away, while the blocking version needs to buffer everything before getting the output. You should be able to get /non-blocking/40000 for instance and your records will start flowing inmediatelly. (Unfortunatelly in my laptop when I try to get 40000 blocking I get a timeout, despite I set the timeout to 300 seconds, have to take a look on that). With non-blocking I tried 100000 and also works fine, but of course you will need to wait a lot more to get the full 100k records. I also tryied 1000000 records but didn't have the patience to wait for it, :(, it looked fine after 300k something records that I interrupted it anyway. Hope the example helps. It prints some extra information with each record (PID of the Mojo daemon, PID of Mojo::Pg, some timers) that you probably don't need. El jueves, 11 de junio de 2015, 10:48:51 (UTC-3), Allan Cochrane escribió: > > > > On Thursday, 11 June 2015 01:33:03 UTC-5, Roger Crew wrote: >> >> > To my mind the callback runs and as part of its functionality schedules >> itself for later execution, it doesn't invoke itself directly as >> 'classical' recursion. >> >> This much is correct, i.e., you're only creating a closure once, and all >> calls to it except for the first are coming from the event loop (i.e., each >> time the write buffer is emptied, the callback is invoked). However there >> is still recursion in the sense that the function is referenced from within >> its own body, which means there's a loop of pointers ($cb refers to the sub >> and the sub refers to $cb) that the reference-counting garbage collector >> will never free up unless you do something to break it >> explicitly.(weaken($cb) but do it *after* that first call.) >> >> >> > Ah, that's where the recursion is, thanks. > > Allan > > -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
