DjangoBot: #celery

padt: seen him around, some guy at IBM

or not seen, tweeted with :)

aha

he had awesome slides at leat

you can now apply tasks without having the task class in registry

celery.execute.send_task

not sure about the name yet

send_task("celery.ping", args=[], kwargs={})

asksol: show me the slides :)

I asked him if he could put it up on slideshare

guess I could share it on the mobileme disk

yeah lol

can't view it, need to find a way to rotate the pages :/

ctrl-left in evince

in case you're using stock ubuntu..

jupp just found out

in os x preview it's Cmt+L

underseapilot: any new news on your evaluation of the new behaviour?

behavior

would be nice to do a bugfix release asap

asksol, i'm buried with other work atm, i might get back to it tomorrow. mostly seems good, but still have a few loose ends to track down.

like?

not necessarily celery related problems, but problems that have come up in the context of upgrading celery.

ah

e.g. the big one right now is something is causing the python loader under wsgi to freakout and be unable to find even core modules.

that happens because of the celery upgrade?

no, i don't think directly. but i have to fix it be able to finish playing around with the new celery.

right, of course :)

i'll deploy it here today

i had to make two changes in bin/celeryd.py - http://pastie.org/836780

the first is just a typo, the second is related to proper shutdown. without it i get zombies or detached children that never go away.

ah, yeah

I already fixed that

oh

the TERM handler?

again, i haven't had time to finish testing, but if you're deploying thought i'd mention it.

yah.

but it's really about calling stop in the parent process, not TERM per se.

yeah, I thought SystemExit did that

at least it did in my testing, but maybe there are platform differences

platform/version

platform, version and context, i.e. running under a shell, or supervisord, and so on.

yeah, ok

I'll add that then

gha. all of this feels really hackish

i agree.

it seems like it should be a solved problem, but i haven't found the library that solves it yet.

I pretty much expected a standard platform independent way of handling termination at least

and that finally clauses was executed by default on all signals except KILL

last time I had to catch term was in C

well, it's entirely possible there's another way to code it.

again, if i could get you a test this would probably be alot easier. :(

hrm

is there a way to know how many times something has retried

e.g. if its the ifnal retry i want to perform an action

you could catch MaxRestartsExceededError

i'm not sure if that gets thrown at the end of the nth retry or the beginging of the n+1th retry, but it shouldn't be too hard to figure otu

hm alright

I wish there were a better way to stop duplicate tasks :)

you know actually im just gonna make a @singular decorator that just runs the locking params

asksol : thanks for the help on friday , have got the redis backend working (I think)

now I have a question about the celerybeat scheduler ... is it possible to add/delete/change tasks without having to restart the celerybeat service?

asksol: ping

hey

davidcramer: kwargs["task_retries"]

or, @task def foo(x, y, task_retries=0):

well, you probably know the drill. there's a standard keyword argument

catching MaxRestartsExceeded is a nice solution though

it's nice if you only waned to override the action of when it's come far enough. if you wanted to keep retrying infinetely but do something on say the 5th, task_retries would be the way to go

yeah, I definitely like catching it. readable and simple

asksol: when does it get raised? at the end of nth or the start of nth+1

answering my own question ... I assume I can use tasks.register and tasks.unregister with an instance of a periodic task, and that the scheduler will automatically add/delete/change that task on it's next run?

otherjacob: it uses task_retries + 1, and raises it if it's > max_retries

and it raises it before it gets to apply it

awesome to note

i'm hoping we can get on 1.0 before too long. still a few freebsd+mp issues to sort out

oh

stovenator: it doesn't work quite like that

bbl

asksol: if it doesn't work like that, is there a way to register tasks after the beat service has started?