On 21 Aug 2012, at 17:54, James R. Leu wrote: > Chakkit et. al. > > Catalyst::Plugin::RunAfterRequest ended up being the easiest first step. > Thank you Chakkit, for the suggestion. > > Now that I have this implemented I'm seeing why a work queue system > is needed if this fix needs to be more then an interim solution. > I quickly use up all the child processes, and simply adding more children > process will not scale. > > My thought is to implement a hybrid work queue Run after Request (RaR) > system. Where the work queue contains the closures that would > normally be handed to RaR.
Why? I mean, you need very minimal info here - you need to persist a 'work to do' thing to the DB, just log that to a message queue (where something picks it up later).. The message is very minimal, like { type => "Job::FooBar", id => "xxxx" } Much simpler and easier + lower coupling - the stuff that implements the job can change independently of the app. Cheers t0m _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/