Korzystanie akord django-seler, celery.chord_unlock utrzymuje wykonujący zawsze niestawienie dostarczonego zwrotnego

Question

używam Django seler Redis uruchomić kilka zadań tak:

header = [ 
    tasks.invalidate_user.subtask(args = (user)), 
    tasks.invalidate_details.subtask(args = (user)) 
] 

callback = tasks.rebuild.subtask() 

chord(header)(callback) 

Więc w zasadzie takie same, jak określono w documentation.

Moim problemem jest to, że gdy ten akord zadanie nazywa, celery.chord_unlock zadanie utrzymuje powtórzeń zawsze. Zadania w header kończą się pomyślnie, ale ponieważ nigdy się nie kończą, callback nigdy nie jest nazywane.

Zgadywanie, że moim problemem jest brak możliwości wykrycia, że ​​zadania od header zostały zakończone, przejrzałam dokumentację, aby sprawdzić, jak można to dostosować. Znalazłem a section, opisujące sposób zaimplementowania synchronizacji, podano przykład, czego mi brakuje, to w jaki sposób mogę wywołać funkcję przykładową (tzn. Czy istnieje sygnał do tego?).

Ponadto istnieje notatka, że ​​metoda ta nie jest używana z Redis backend:

ten jest wykorzystywany przez wszystkie backendów wynikowych z wyjątkiem Redis i Memcached, które przyrost licznik po każdym zadaniu w nagłówku, a następnie nałożeniem oddzwanianie, gdy licznik przekroczy liczbę zadań w zestawie.

Ale też mówi, że podejście Redis jest lepsze:

Podejście Redis i Memcached jest znacznie lepszym rozwiązaniem

Jakie podejście jest? W jaki sposób jest wdrażany?

Dlaczego więc chord_unlock nigdy nie zostało wykonane i jak mogę wykryć zakończone zadania header?

Używam: Django 1.4, seler 2.5.3, 2.5.5 django-seler, Redis 2.4.12

Answer 1

Nie masz przykład zadań, ale miałem ten sam problem i moje rozwiązanie może mieć zastosowanie.

miałem ignore_result=True na zadania, które miałem dodanie do cięciwy, zdefiniowane tak:

@task(ignore_result=True) 

Widocznie ignorując wynik sprawia, że ​​jest tak, że zadanie chord_unlock nie wiedzą, że są kompletne. Po usunięciu ignore_result (nawet jeśli zadanie zwraca tylko true) akord zwany callback poprawnie.

Answer 2

Miałem ten sam błąd, zmieniłem brokera do RabbitMQ i chord_unlock pracuje aż do moich zakończeniu zadania (zadania 2-3 minuty)

podczas korzystania Redis zakończeniu zadania i chord_unlock tylko ponowiona jak 8-10 razy co 1s, więc wywołanie zwrotne nie zostało wykonane poprawnie.

[2012-08-24 16:31:05,804: INFO/MainProcess] Task celery.chord_unlock[5a46e8ac-de40-484f-8dc1-7cf01693df7a] retry: Retry in 1s [2012-08-24 16:31:06,817: INFO/MainProcess] Got task from broker: celery.chord_unlock[5a46e8ac-de40-484f-8dc1-7cf01693df7a] eta:[2012-08-24 16:31:07.815719-05:00]

... just like 8-10 times....

zmieniając broker pracował dla mnie, teraz jestem testowania @Chris rozwiązanie i moja funkcja zwrotna nigdy otrzymuje wyniki z podzadań nagłówka: S, tak, że nie działa na mnie.

---

seler == 3.0.6

Django == 1,4

django-seler == 3.0.6

Redis == 2,6

Broker: Redis-2,4 .16 na Mac OS X

Answer 3

Może to spowodować problem taki, że; Z dokumentacji;

Uwaga:

Jeśli używasz akordy backend wynik Redis a także przesłanianie metody Task.after_return(), należy upewnić się, aby zadzwonić super metody wywołania zwrotnego lub inny akord nie będzie być stosowane.

def after_return(self, *args, **kwargs): 
    do_something() 
    super(MyTask, self).after_return(*args, **kwargs) 

W moim rozumieniu, jeśli masz nadpisane after_return funkcję w swoim zadaniu, należy go usunąć lub przynajmniej nazywając super- jeden.

Dół tematu: http://celery.readthedocs.org/en/latest/userguide/canvas.html#important-notes