Django-sedano corda, celery.chord_unlock mantiene l'esecuzione di sempre non chiamando la callback fornito

Question

sto usando Django sedano con Redis per eseguire alcuni compiti come questo:

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

callback = tasks.rebuild.subtask() 

chord(header)(callback) 

Quindi, in pratica lo stesso come indicato in documentation.

Il mio problema è che quando viene chiamato questo accordo di attività, l'attività celery.chord_unlock continua a riprovare per sempre. Le attività in header terminano correttamente, ma a causa di chord_unlock non viene eseguita, callback non viene mai chiamato.

Suppongo che il mio problema è di non essere in grado di rilevare che le attività da header sono finite, ho girato la documentazione per vedere come può essere personalizzato. Ho trovato a section, descrivendo come la sincronizzazione è implementata, c'è un esempio fornito, quello che mi manca è come faccio a ottenere che la funzione di esempio venga chiamata (cioè c'è un segnale per questo?).

Inoltre c'è una nota che questo metodo non viene utilizzato con Redis backend:

Questo è usato da tutti i backend risultato eccetto Redis e Memcached, che incrementa un contatore dopo ogni operazione nell'intestazione, quindi applicando la richiamata quando il contatore supera il numero di attività nel set.

Ma dice anche, che l'approccio Redis è meglio:

L'approccio Redis e Memcached è una soluzione molto migliore

Quale approccio è quello? Come viene implementato?

Quindi, perché chord_unlock non è mai stato fatto e come posso renderlo rilevato finito attività header?

sto usando: Django 1.4, sedano 2.5.3, django-sedano 2.5.5, 2.4.12 redis

Answer 1

Non è un esempio dei vostri compiti, ma ho avuto lo stesso problema e la mia soluzione potrebbe applicarsi.

ho avuto ignore_result=True sui compiti che mi stava aggiungendo ad un accordo, definito in questo modo:

@task(ignore_result=True) 

Apparentemente ignorando il risultato fa in modo che il compito chord_unlock non sa che sono complete. Dopo aver rimosso ignore_result (anche se l'attività restituisce solo true), l'accordo chiama correttamente la callback.

Answer 2

Ho avuto lo stesso errore, ho cambiato il broker a RabbitMQ e chord_unlock sta lavorando fino a quando i miei finiture compito (2-3 minuti compiti)

quando si utilizza Redis le finiture compito e chord_unlock solo ritentato come 8-10 volte ogni 1 s, quindi la richiamata non si stava eseguendo correttamente.

[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....

cambiare mediatore ha funzionato per me, ora sto testando @ Chris soluzione e la mia funzione di callback non riceve mai i risultati delle attività secondarie di intestazione: S, quindi, non è così per me funziona.

---

sedano == 3.0.6

Django == 1.4

django-sedano == 3.0.6

Redis == 2,6

mediatore: Redis-2.4 .16 su Mac OS X

Answer 3

Ciò potrebbe causare un problema tale; Dalla documentazione;

Nota:

Se si sta utilizzando gli accordi con il backend risultato Redis e anche l'override del metodo Task.after_return(), è necessario assicurarsi di chiamare il metodo eccellente altrimenti la richiamata corda non sarà essere applicato.

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

Come la mia comprensione, se avete sovrascritto after_return funzione nel vostro compito, deve essere rimosso o almeno chiamando eccellente uno.

Fondo dell'argomento: http://celery.readthedocs.org/en/latest/userguide/canvas.html#important-notes