4 ms·
I actually wrote a solution for this exact problem for SUSE Hack Week 2018. I made a small job tracking / state tracking system using Perl and nanomsg. See http
by nanoscopic 8y ago
I actually wrote a solution for this exact problem for SUSE Hack Week 2018. I made a small job tracking / state tracking system using Perl and nanomsg. See https://github.com/nanoscopic/galear/blob/master/client/srv/www/galclient/lib/Server/NanoState.pm https://github.com/nanoscopic/galear/blob/master/client/srv/...
Essentially it is just a small server that listens on a nanomsg queue for new tasks. Workers can then be created that periodically ping the server to grab a task off the queue. Optimally a nanomsg queue would also be used to queue the tasks out to the workers; I just build it this way since I could implement the entire thing within hours and continue on with my hack week project.
The benefit of using nanomsg over several of the other message queues suggested here is that nanomsg is a brokerless message queue, meaning that there need not be any central queue tracking everything.
It is somewhat ironic in that sense that I essentially built a message broker using it, but it demonstrates the simplicity of using nanomsg.
While the code there is written in Perl, it could easily be ported to any of the other many languages nanomsg has libraries for.
In summary, to handle long running background jobs:
1. Create as many "worker" processes as you need to be able to simultaneously process multiple long running background jobs.
2. Have a way to feed tasks into those workers ( in my case a central task tracker )
3. Have a way to feed back status of the workers to something central so you can tell what is going on