[uWSGI] Spooler and mules for cron jobs

Roberto De Ioris roberto at unbit.it
Tue Oct 29 16:35:55 CET 2013

> Hi
> I'd like to better understand the differences between the spooler and
> mules.
> I have a Python webapp where I need to execute some cron jobs in the
> background, outside the main workers. I see that I can use the target=
> argument of the @cron decorator (undocumented, by the way) with a value of
> "spooler" or "mule".
> What's the difference between using the spooler vs. a mule? (or N spooler
> processes vs. N mules) As far as I can see, the spooler has a directory of
> tasks, so it can queue a large number of them and the queue survives a
> restart. With mules, on the other hand, a signal is only answered if there
> is a free mule when the signal is sent. Is this correct? What happens to a
> @cron with target=mule if all the mules are busy? Is it just dropped?
> Therefore, what is the best way to avoid having two instances of the same
> cron overlap? Say I have a cron every 10 minutes, but if it takes more
> than 10 minutes, I don't want a second instance overlapping the first. I
> can use a numbered mule, dedicated to that cron, so that the signal is
> dropped if the mule is still busy. Is this correct?
> Is there a way to disallow cron overlapping, using the spooler?
> Is there a way to give names to the mules? Or are the names fixed to
> mule1, mule2…?

>From the @cron point of view spoolers and mules are the same thing. They
are only processes waiting for signals. Both will discard the signal of
the queue is full (obviously it will be logged).

>From what you describe you'd better check the --cron option, and better,
the --unique-cron variant that avoid to task of the same cron-group to

cron = -1 -1 -1 -1 -1 slow_script
unique-cron = -1 -1 -1 -1 -1 slower_script

Roberto De Ioris

More information about the uWSGI mailing list