Zamanlanmış işte iki soruyu ayrı tutarım: ne yapılacak ve ne zaman yapılacak? Quartz'ta IJob ile Trigger ayrımı tam bunu sağlar. Arşivimdeki küçük zamanlayıcı örneği üzerinden bakınca alarmı kurmakla işin başarıyla tamamlanmasının aynı olay olmadığı daha net görünüyor.
Job davranışı, trigger zamanlamayı taşır
HelloJob yalnız konsola job yazar. JobBuilder bu davranış için bir job tanımı oluşturur; TriggerBuilder o tanımın çalıştırılacağı programı kurar. Örnek Quartz 3.x API biçimindedir ve uygun Quartz paketiyle bir konsol projesine yerleşir. Arşiv tekniğini gösteren bağımsız bir deneme, kalıcı üretim zamanlayıcısı değildir.
using Quartz;
using Quartz.Impl;
var scheduler=await new StdSchedulerFactory().GetScheduler();
await scheduler.Start();
var job=JobBuilder.Create<HelloJob>().WithIdentity("demo").Build();
var trigger=TriggerBuilder.Create().StartNow()
.WithSimpleSchedule(s=>s.WithIntervalInSeconds(1).WithRepeatCount(1)).Build();
try { await scheduler.ScheduleJob(job,trigger); await Task.Delay(2500); }
finally { await scheduler.Shutdown(waitForJobsToComplete:true); }
public class HelloJob:IJob
{
public Task Execute(IJobExecutionContext context)
{ Console.WriteLine("job"); return Task.CompletedTask; }
}WithRepeatCount(1) toplam bir çalışma anlamına gelmez: ilk çalışmanın ardından bir tekrar, yani normal koşullarda iki çalışma beklenir. StartNow ilk tetiklemeyi hemen uygun hale getirir. Buradaki 2.5 saniyelik Task.Delay yalnız gözlem penceresi; yoğun bir makinede işin tam o süre içinde iki kez bittiğini garanti eden test mekanizması değil.
Kimlik, davranış sınıfından farklı bir kavram
JobKey bir job tanımının kimliğidir. Aynı IJob sınıfından farklı kimliklerle birden çok iş tanımlanabilir; aynı işi farklı trigger'lar da çalıştırabilir. Bu sayede davranışı kopyalamadan ayrı programlar kurulur. Ama yeniden başlatmada aynı kimliği tekrar eklemek ve mevcut tanımı değiştirmek için de açık bir politika gerekir.
Planı veritabanından üreten bir uygulamada “her açılışta yeni job adı üret” yaklaşımı eski tanımları biriktirebilir. Kararlı kimlik ve güncelleme/silme davranışı, çalışma saatinin kendisi kadar önemlidir. Trigger ile job ilişkisinin görünür olması bu yaşam döngüsünü izlemeyi kolaylaştırır.
Aynı iş bir öncekisi bitmeden başlayabilir mi?
Bir işin süresi tetikleme aralığından uzun olabilir. DisallowConcurrentExecution seçeneği kullanılacaksa kapsamı doğru anlaşılmalı: aynı job tanımının eşzamanlı çalışmasını sınırlar; aynı sınıftan üretilmiş her farklı JobKey'i uygulama genelinde tekilleştirmiş olmaz. Birden çok süreçte tek çalışma gerekiyorsa job store ve cluster yapılandırması da değerlendirilir.
Bu koruma işin yan etkilerini otomatik idempotent yapmaz. Süreç bir işlemden sonra ama sonucu kaydetmeden kapanırsa sonraki tetikleme aynı işi yeniden yapabilir. Benzersiz iş anahtarı, sonuç durumu veya sürüm kontrolü gibi bir veri kuralı zamanlama katmanının dışında da bulunmalıdır.
Kaçırılan çalışma için iş kararı gerekir
Uygulama kapalıyken zamanı gelen işler, kalıcı store ve misfire politikasına göre ele alınır. Kaçırılan her çalışmayı telafi etmekle yalnız son durumu güncellemek farklı gereksinimlerdir. Günlük rapor üretimi ile “şu anki bakiyeyi yenile” işlemi aynı kaçırma davranışını istemeyebilir. Quartz'ın bir varsayılanını seçilmiş iş kuralı gibi sunmam.
Örnekteki finally, scheduler'ın kapatılmasını ister; waitForJobsToComplete devam eden işleri bekleme tercihidir. Bunun sonsuz beklemeyi makul hale getirdiği anlamına gelmez. Gerçek I/O çağrılarında iptal token'ı ve zaman aşımı gerekir; uygulamanın kapanış bütçesiyle birlikte tasarlanır.
İki satır log yerine tamamlanan işi sınamak
Demo için job çıktısını görmek yeterli bir gözlem olabilir. Otomatik testte ise belirli iş kimliğinin kaç kez tamamlandığını güvenilir bir sayaç veya test store üzerinden izlerim. İptal edilen ve hata veren çalışmayı başarılı tamamlanmadan ayırırım. Zamanlayıcı tetikledi diye e-posta gönderildiğini veya veritabanı kaydının oluştuğunu varsaymam.
Quartz 3.x job ve trigger modeli; SimpleTrigger tekrar ve misfire seçenekleri.