işyerinde birkaç gündür saç baş yolduran bir hatanın keyword’ü “timeout”.
Bendeki durum tam olarak şu: IIS te üzerinde host edilen bir web servise ( asmx ) çağrı yapıyoruz. Biraz uzun sürecek bir iş parçacığı. Mesela 40 dakika. ( IIS te 40 dakikalık bir iş mi yapılır diyen bir sürü kaynak var, haklılar da, ama var işte, ne yapalım, sorunu çözmek zorundayız ) . Normalde IIS 40.dakikanın sonunda client’a işin bittiğini haber veren bir cevap dönmesi lazım. Benim yaşadığım sorunda bu cevap client’a bir türlü GELMİYORDU. Bu durum genelde “IIS No Response after 15/30 minutes” şeklinde tarif ediliyor.
Bu durumu Google’ladığınızda karşınıza iki öneri çıkıyor. 1-) client timeout’unu artırın 2-) IIS te web.config de executionTimeout değerini artırın.
Fakat benim yaşadığım durum bunlardan her ikisine de uymuyordu. Çünki bu değerler olması gerektiği şekilde yeterli büyüklükte idi.
IIS’in config parametrelerinde daha farklı timeout mekanizmaları bulamayınca bu sorunun kaynağının IIS olmama ihtimali güçlendi ve farklı yerlere bakmaya başladık. Ve sorunun kaynağının firewall daki default timeout süresi olduğunu gördük.
Bunu nasıl anladık?
Görevi belirtilen süre kadar bekleme olan bir metod yazdık. Bu metodu farklı yerlerden denemeye başladık. En son asmx lerin yüklü olduğu server’a bu uygulamayı attık ve localhost üzerinden web servis çağrısı yaptık. Burada herhangi bir cevap dönmeme sorunu ile karşılaşmadık. Bu bizim için kırılma noktası oldu ve kısa sürede server’a erişimi noktalarını denetleyen yapılara ve firewall ayarlarına ulaştık.
Umarım birine faydalı olur.
Etiketler: after 30 minutes, asmx, IIS, no response, timeout, web service request
Emre ERDEM 
Nisan 15, 2017, 8:30 pm |
Bu tip uzun süren işlerde sonuç bekleme sorununu, client’a işin durumunu sorgulayan ayrı bir servis vererek de çözebilirsiniz. İlk adımda client asenkron bir biçimde servisi çağırır ve bırakır, sizi beklemez. Daha sonra durum sorgulama servisiyle ara ara gelir bizim iş ne oldu diye sorar…
Nisan 17, 2017, 12:48 pm |
Önerdiğiniz yöntem de makul, hatta yapmayı düşünmüş fakat işyerimizdeki “Job Yönetim Aracı” ( ActiveBaTCH) nın böyle bir desteği olmadığı için yapamamıştık.
ActiveBatch “Tek bir çağrı yaparım, o çağrın başarılı ise başarılı sonuçlanırım, sorunlu ise hatayı rapor ederim” diyor.
Eğer bana “İşi önden tetikleyeceğim bir servis ver, sonra da bitiş durumunu sorgulayacağım başka bir servis ver” diyebilse idi ifade ettiğinzi bir tarz kurabilirim.
Bu yazıda, timeout zımbırtısının firewall kaynaklı bir nedenini dikkate vermeye çalıştım.
Başka bir yerde, başka bir iş esnasında her an benzer bir durum yaşanabilir.