https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15032 --- Comment #36 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to David Cook from comment #35)

(In reply to Tomás Cohen Arazi from comment #34)

...

This is worth discussing in koha-devel, and IRC meeting or Marseille, but I think we should have a job queue in the lines of what David proposes. And I would add maybe the use of ZeroMQ to possibly notify other services.

I agree about opening up the discussion in another forum like koha-devel, IRC, or Marseille.

I'm intrigued by the use of ZeroMQ. How do you see that working, Tomás? When I first started thinking about background processing, I thought using a message queue would be a good idea. Since then, I've used an embedded ActiveMQ with the Fedora repository a bit, but that publishes notifications about record changes. Celery uses a message queue for sending out tasks and then it can use a backend like Redis for storing task results.

I think if we use a database for a job queue, that would replace the message queue? Or are you meaning using a message queue for notifying other services like an indexer that there are imported records to index?

I need to implement a way to hook record/item updates so changes are pushed to an external service. Ideally through the use of plugins so a more generic job queue was the first thing to consider. Then if we replace (say) rebuild_zebra.pl -d with this, we should add a way to inject new 'tasks' derived from this events (so a record update should trigger a zebra/ES indexing step, and also look for things (plugins) that would require actions. It felt simpler if it just sent broadcast messages through a socket to any service listening there. I like ZeroMQ because it doesn't need a server, you just use your own service. So, one event => multiple actions. -- You are receiving this mail because: You are watching all bug changes.