Quartz.net + Task Parallel Library

Sto lavorando per aggiornare un sistema di pianificazione del lavoro che usiamo in-house che utilizza Quartz.net. Osservando la fonte dell'ultima versione di Quartz, ho notato che utilizza ancora la propria implementazione del pool di thread, a differenza del pool di thread molto migliorato (o qualsiasi cosa di System.Threading.Tasks) che ha iniziato a essere distribuito con .NET 4.0.Quartz.net + Task Parallel Library

Sarei curioso di sapere se qualcuno ha implementato con successo un sistema di pianificazione del lavoro che utilizza Quartz.net per le sue funzionalità di pianificazione e TPL per il pool di thread. È relativamente facile scambiare il pool di thread di Quartz con quello di TPL? Quartz è ancora rilevante nel mondo di Google Task? In alternativa, come venduto come sono sugli ottimi miglioramenti con il pool di thread .NET 4.x (consapevolezza di base, code locali, blocco migliorato, ecc.), Il pool di thread di Quartz è abbastanza buono per i processi di background a grana grossa tipici e non vale la pena lo sforzo di forzare il TPL nel mix?

Grazie in anticipo per eventuali approfondimenti sull'utilizzo (o non sull'utilizzo) di questi due strumenti.

fonte

2013-03-02 Todd Menier

Quartz.NET è lì per risolvere un problema leggermente diverso rispetto a TPL. Quartz.NET è concepito per la pianificazione ricorrente dei lavori con un ricco set di funzionalità per il timing di esecuzione . D'altro canto, il TPL è pensato per l'esecuzione parallela altamente performante del carico di lavoro computazionale.

Quindi, in pratica, si usa (di solito) Quartz.NET per la pianificazione di precisione e TPL per carichi di lavoro concienti che devono essere completati il più rapidamente possibile utilizzando tutte le risorse di elaborazione (core ecc.).

Detto questo, direi che l'implementazione del pool di thread utilizzata da Quartz.NET è sufficiente per il lavoro. Ricorda inoltre che Quartz.NET è compatibile con .NET 3.5 e non può utilizzare solo le funzioni 4.0.

Naturalmente, è anche possibile combinare sempre i due nella soluzione.

fonte

2013-03-04 18:08:16

Grazie. Penso che tu abbia confermato la mia impressione che forse non hai bisogno di un pool di thread con super-turbo per eseguire lavori in background non presidiati. –

Ci sono potenziali insidie nell'usare i due in combinazione? Per fare un esempio, voglio pianificare un lavoro che, quando viene attivato, ottiene il suo lavoro dal database e questo lavoro può essere di 50-100 singoli pezzi di lavoro, che voglio fare in un Parallel.ForEach. Ci sono condizioni in cui ciò potrebbe esplodere? – avesse

Dovrebbero funzionare insieme bene. Basta avere le normali routine di registrazione e gestione delle eccezioni in atto. Pensa che se la Main di Program.cs la buttasse, è la stessa cosa. Potresti prendere in considerazione l'impostazione del flag di ripetizione per il contesto in caso di errore oppure attendere la prossima esecuzione: è una buona idea rendere il lavoro idempotente. –

risposta

Problemi correlati