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.


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/

Reply via email to