2013-03-25 11 views
7

Uso il lavoro in ritardo in una configurazione in cui eseguo più worker. Per la mia domanda, non ha molta importanza, ma diciamo che eseguo 10 lavoratori (facendo questo in modalità di sviluppo al momento).Più processi di lavoro in ritardo che iniziano lo stesso lavoro

Il problema che sto avendo è che due diversi lavoratori a volte iniziano a lavorare sullo stesso lavoro, chiamando il metodo perform sul mio oggetto lavoro.

Al meglio della mia comprensione differita Lavoro sta usando il blocco pessimistico per evitare che ciò accada, ma sembra che a volte hanno ancora abbastanza tempo per bloccare rubare il lavoro prima che il primo lavoratore ha il tempo per bloccarlo in realtà.

Sto solo chiedendo se qualcun altro ha riscontrato questo problema, o se è il mio setup che si comporta male. Sto usando Postrgres e questo accade sia nella mia macchina di sviluppo che su Heroku, dove l'ho ospitato.

Cercherò di aggirarlo nei miei lavori, ma è ancora un po 'problematico che ciò accada. Idealmente, non succederebbe mai che un lavoro in ritardo lavori sullo stesso lavoro da due processi.

Grazie!

+0

Vedo qualcosa di simile. Non sono stato in grado di rintracciarlo completamente, ma sembra che tra il controllo di un lucchetto e il blocco, molti operatori stiano afferrando ed eseguendo il lavoro. –

+0

Devo dire che ho trovato che l'impostazione '' 'Delayed :: Worker.read_ahead = 1''' in un inizializzatore sembrava mitigare il problema. –

+0

Avendo lo stesso problema con Resque, non ho trovato una soluzione –

risposta

0

Abbiamo eseguito circa 60 milioni di posti di lavoro in ritardo con 12 lavoratori e non abbiamo mai avuto un rapporto di questo. Qual è l'SQL che il tuo lavoratore in ritardo è in esecuzione? Stai usando una gemma che sta cambiando il comportamento di blocco di Postgres?

Ecco ciò che lo sql DJ assomiglia per me:

UPDATE "delayed_jobs" SET locked_at = '2014-05-02 21:16:35.419748', locked_by = 
'host:whatever.local pid:4729' WHERE id IN (SELECT id FROM "delayed_jobs" 
WHERE ((run_at <= '2014-05-02 21:16:35.415923' 
AND (locked_at IS NULL OR locked_at < '2014-05-02 17:16:35.415947') 
OR locked_by = 'host:whatever.local pid:4729') AND failed_at IS NULL) 
ORDER BY priority ASC, run_at ASC LIMIT 1 FOR UPDATE) RETURNING * 

Vuoi avere il blocco dei problemi con qualsiasi altro codice? Potresti provare a eseguire due binari sessioni di console e facendo questo:

console Sessione 1:

User.find(1).with_lock do sleep(10); puts "worker 1 done" end 

console Sessione 2:

User.find(1).with_lock do sleep(1); puts "worker 2 done" end 

Inizia sia quelli allo stesso tempo, e se 2 fine prima 1, hai un problema di blocco più generale che il lavoro in ritardo.

Problemi correlati