New functionality in Cantella::Worker
I just released a new version of Cantella::Worker and I'm really happy with the improvements. I updated Cantella::Worker::Manager::Prefork and added a couple of options to add a little more fine-grained controls to the worker processes, such as whether the workers should detach from the manager's session or not and a way to adjust the priority of worker processes. More importantly, I added the "program name" attribute and functionality and I made children automatically shut down if their manager dies, so that you never have an unsupervised worker pool. Special thanks to Rocco Caputo for his help. So, here's an example so you can see the progress made:
Here is the script we will be running:
Now, Here is how we interact with it:
And Finally, this is the log of events:
neat huh?
I blog about Perl.
Hey,
I like where you are heading with this and am probably going to get buy int today to use it as part of our $work related job queue. Some things I am thinking of that I'd like (please let me know what you think before I fork github and introduce stuff you think belongs else where)
1) Ability to define one or more worker 'namespaces'. The idea here is that you'd specify a module namespace and be able to delgate work to multiple jobs. Not sure what you think of this idea, but basically what I am trying to avoid is needing to run a separate manager for each and every job (although I can see the advantage of that as well, feel free to talk me out of it :) )
2) Some additional bits to isolate the code to start/stop/manage the server, maybe similar to Server::Starter (although that's aimed at webservers it seems)
Thanks for sharing this!
John,
"Namespaces" are something you can implement through your worker itself. I, personally, use Cantella::Worker::Role::Beanstalk to manage my jobs, and implement something like it. What I do is watch more than one tube so I can get multiple types of jobs, then, in my "work" method, I simply use an if/elsif/else block to delegate those jobs to different methods. You could use a dispatch table too, I guess. I just really wanted to distance myself from worker systems that doe this and have a single set of workers doing every job.
In the future I may include a more DWIMy way of achieving this, but I am presently not happy enough with any of the designs I've come up with to include them in the core package.