Wolverine ve CritterWatch ile tekrarlayan işler

Wolverine 6.34'ten bu yana zamanlanmış işleri sıradan bir mesaj olarak ele alıyor; 6.52 ve 6.61 ise schedule'ları çalışma sıklığına göre durable inbox ve timer agent olmak üzere iki yola ayırdı. CritterWatch 1.2, tüm filo genelinde schedule'ları görüp durdurmayı, devam ettirmeyi ve tetiklemeyi sağlıyor; MCP üzerinden de.

Kilit noktalar

• Tekrarlayan iş, normal bir Wolverine mesajı artı tek satır `ScheduleRecurring` kaydından ibaret; retry, outbox, dead letter ve tracing ek kod gerektirmiyor.
• Schedule'lar failover yapabilen tek bir agent üzerinden ve schedule adı ile occurrence zamanından üretilen deduplication id sayesinde cluster başına bir kez çalışıyor.
• 6.52'den itibaren haftalık en kısa aralık yolu belirliyor: 15 dakika ve üzeri önceden yazılmış inbox envelope'u, daha hızlısı in-memory timer agent kullanıyor.
• Timer yolunda occurrence inbox satırı bırakmıyor, bu yüzden node failover'ında kaybolan tick'ler hiç çalışmıyor; scheduled-message occurrence'ları ise yine tetikleniyor.
• 6.61'de gelen `SkipWhileRunning()` yavaş bir handler'ın tick biriktirmesini engelliyor, timer'lar artık saniye bazlı schedule'ları da destekliyor.
• CritterWatch 1.2'nin Schedule Explorer'ı son çalışma durumunu, cron'un düz dil karşılığını gösteriyor ve operatörlerin schedule'ları durdurmasını, devam ettirmesini veya tetiklemesini sağlıyor; MCP üzerinden de.

Wolverine 6.34 ile zamanlanmış işler sıradan bir mesaja dönüştü: `opts.Schedules.ScheduleRecurring<T>(cron)` çağrısı, o mesajı cron ifadesine göre yayınlıyor; böylece handler transactional outbox, retry, dead letter, middleware ve OpenTelemetry span'leri (`wolverine.recurring.occurrence`) gibi broker mesajlarının tüm altyapısını bedavaya kullanıyor. Zamanlamayı tek bir cluster agent'ı sahiplendiği ve her occurrence deterministik bir deduplication id taşıdığı için iş node başına değil cluster başına bir kez çalışıyor.

6.61'den itibaren hangi yolun kullanılacağını iki occurrence arasındaki süre belirliyor: haftalık en kısa aralık 15 dakika ve üzerindeyse occurrence durable inbox'a önceden yazılıyor, daha hızlı schedule'lar ise her biri için ayrı bir in-memory timer agent üzerinde çalışıyor. `SkipWhileRunning()` üst üste binen tick'leri atlıyor, `UseTimer()`/`UseScheduledMessages()` seçimi elle değiştiriyor. CritterWatch 1.2 ise Schedule Explorer ile tüm filo genelindeki schedule'ları görüntüleyip durdurmayı, devam ettirmeyi ve tetiklemeyi sağlıyor; MCP üzerinden de erişilebiliyor.

Gerçek dünyada kullanımı

• Belirli bir saat diliminde 07:00'de çalışan ve crash sonrası da tetiklenmesi gereken gecelik rollup; bu yüzden önceden zamanlanmış inbox yolunda kalır.
• Üst üste binen tick'lerin atılmasının ve rolling deploy sırasında bir tick kaybının zararsız olduğu beş saniyelik envanter polling'i.
• Operasyon ekibinin bir olay sırasında gürültülü payer-feed kontrolünü durdurup sonrasında deploy yapmadan elle tetiklemesi.
• Bir AI agent'ın MCP üzerinden schedule sağlığını sorgulayıp son çalışmada hangi işlerin başarısız olduğunu bildirmesi.

Neden önemli

Zamanlanmış işler, operatörlerin göremediği ve deploy olmadan durduramadığı ikinci bir scheduler'da yaşamak yerine mesajlaşma katmanında zaten ödediğiniz güvenilirliği ve gözlemlenebilirliği devralıyor.

Benzer haberler

• CritterWatch 1.1 dead letter'ları hata nedenine göre gruplayıp tek işlem olarak yönetirJXJasperFx (Critter Stack) Blog29 Eki
• Visual Studio Marketplace'e PAT olmadan güvenli yayın: Trusted PublishingMDMicrosoft for Developers Blog28 Eki
• AWS Transform'u GitHub Copilot'a MCP ile bağlamakAWAWS .NET on AWS Blog27 Eki