Alternatives to collective.cron and

Hi all,

we are facing some problems with collective.cron and and decided to look for alternatives. Contrary to others (like this post) we do still need a ZODB connection, as our main async jobs are about doing objects post processing work.

Is there any product for that? So far we did a quick and dirty plain system cronjob call to a browser view, but that's unreliable as well, as the instance can be down, etc etc

If its object post processing and queuing is the main thing collactive.zamqp works really fine - I used it in several projects already w/o any problems.

It needs a RabbitMQ or similar AMQP service running.

If I would need this feature in a new project I would look at collective.taskqueue first too - but I do not have any experience with it.

It looks very promising and uses Redis queues (so redis is needed).

Your task has two subtasks: job queuing and job execution.

I am using "zc.queue" for job queuing.

For job execution, I am using normal cron jobs which start a script with "bin/client1 run ..." to do the work. Of course, this requires the use of "ZEO" to have access to the ZODB by several independent processes.

Thanks @jensens and @dieter for your answers, zc.queue sounds really integrated (and thus transaction aware), job execution is another thing...

We have a mix of jobs to be run in a cron-like fashion (once per day/week, etc) and on-demand ones (like objects post processing), so using plain cron jobs to trigger a simple view to queue jobs looks like a good approach, then the job processor(s) can run all day long serving other requests while at the same time they take care of the jobs queued.

We use c.taskqueue. its light and works well.
Its not directly integrated with c.cron but it would be nice to see c.cron extended to other queues.