Celery 3.0 has been released
docs.celeryproject.org
docs.celeryproject.org
That said, I did run into an issue with periodic tasks (our bread and butter at Zapier). Detailed here: https://github.com/celery/celery/issues/844
Thanks a bunch Ask.
# incomplete partial: add(?, 2)
>>> s2 = add.s(2)
# resolves the partial: add(8, 2)
>>> res = s2.delay(8)
>>> res.get()
10
>>> import functools
>>> abc = lambda a, b, c: (a, b, c)
>>> bc = functools.partial(abc, "a")
>>> bc("b", "c")
('a', 'b', 'c')
2. http://docs.python.org/library/functools.html#functools.part...
The reason is that I found that it better matches what you use them for in Celery, since they are used e.g. to forward results from the previous tasks to a callback. Often you have a signatures like: def blur_image(image, amount=1), where the partial is used like render_image.s(file) | blur_image.s()
functools.partial is usually used the other way; it's most common to create functools.partials where the first argument is satisfied.
Looking forwards to experimenting with the non-multiprocessing worker - something in my current setup regularly leaks memory, and for the above-mentioned reason I can't automatically recycle worker processes to clean it up.
The large number of deletions is a pretty good sign of the project's health. Congrats!
Excellent job celery team !
If you mean the one queue for every task behavior of the amqp result backend then that is also a yes. Usually with replies in amqp you create one queue for every client, but Celery is often used in a web context where the process that initiated the task may not be the same process that collects the reply, so this is why it uses one queue for every task (it's also documented).
There's an experimental result backend for RPC-style replies, that uses transient messages and one queue per client: http://github.com/celery/celery/tree/kombuRPC
You could set the exchange type of the results exchange to be topic too, that way you would both have result queues and you could additionally bind a queue to the results exchange to get a copy of all the messages sent there. But if you don't need to listen for individual results then I'd rather just send messages manually. You have both connection and producer pools in Celery, so it's rather convenient to combine kombu with celery.
So you can use Celery as a driver for beanstalk in Python.
Here goes: http://pastie.org/4216467
It's probably due to redis' INFO command giving different values. Now would be a great time to get it sorted out, too.
* 2.4.11
* Made the INFO command more tolerant of Redis changes formatting. Fix for #217.
See, folks? Celery is amazing in multiple ways.