CritterWatch 1.1 dead letter'ları hata nedenine göre gruplayıp tek işlem olarak yönetir
CritterWatch 1.1, dead letter'ları exception türü yerine hatanın kendisine göre gruplayarak tüm servis ve veritabanlarında tek satırda gösteriyor. Bir grup üzerinde replay, archive, restore ya da discard işlemini tek bir izlenen operasyon olarak, gerekçesiyle birlikte çalıştırmak mümkün. Wolverine tabanlı mesajlaşma kuran .NET ekipleri için olay yönetimini belirgin biçimde kolaylaştırıyor.
Kilit noktalar
- Gruplama Wolverine 6.54 ve üstündeki parmak izlerine dayanıyor; eski istemciler exception türüne göre gruplanır
- Replay, archive, restore ve discard işlemlerinin her biri zorunlu bir gerekçe ister
- Bir gruba aynı anda yalnızca bir operasyon çalışabilir
- Archive mesajları silmeden kuyruk sayaçlarından ve DLQ uyarılarından çıkarır
- MCP üzerinden discard önce önizleme döner; onay belirteci 5 dakika geçerlidir
- Yeni RBAC izinleri: dlq.archive ve dlq.note
JasperFx, CritterWatch 1.1 sürümünü yayımladı. Bu sürüm dead letter yönetimini exception türü yerine hatanın nedenine göre düzenliyor. Wolverine 6.54 her dead letter için parmak izi üretiyor ve CritterWatch bu izleri servisler arasında birleştirerek aynı hatayı tek satırda gösteriyor. Böylece bir paylaşılan paketteki hata, dört servis ve birçok veritabanında dağınık kayıtlar yerine tek bir olay olarak görülüyor.
Grup üzerindeki replay, archive, restore ve discard işlemleri tek bir operasyon olarak çalışıyor ve her işlem için bir gerekçe zorunlu. İlerleme veritabanı bazında takip ediliyor, bittiğinde Check re-failures sayısı yeniden başarısız olan mesajları gösteriyor. Archive, mesajları silmeden kuyruktan ve sayaçlardan çıkarıyor. Aynı akış MCP sunucusu üzerinden AI ajanlarına da açık; discard işlemi ise önce önizleme ve onay belirteci gerektiriyor.
Gerçek dünyada kullanımı
- Ödeme sağlayıcısı kesintisinden sonra birden fazla servisteki başarısız mesajları tek işlemle yeniden işleme almak
- Paylaşılan bir NuGet paketindeki hatanın tüm tenant veritabanlarına yayılmasını tek satırdan izlemek
- Ortak bir partner sorunu sürerken mesajları arşivleyip hata düzelince geri yüklemek
Neden önemli
Dead letter olaylarını hata nedenine göre yönetmek, yanlış replay ve gereksiz silme riskini azaltır. Gerekçe kaydı ve yeniden başarısızlık sayacı, olayın gerçekten bitip bitmediğini doğrulamanızı sağlar.
Benzer haberler
- C# interface'lerinde collection dönüş tipleri: interface, view ve snapshot farkıNick Cosentino (Dev Leader)2 gün önce
- Critter Stack: mesaj kaybı, kapanış ve multi-tenancy düzeltmeleriJasperFx (Critter Stack) Blog3 gün önce
- Dapper FluentMap 3.6: 2.0'dan bugüne neler değiştiDEV Community: #dotnet5 gün önce