În AWS, o sarcină este plasată pe o instanță EC2 și o aplicație ASP.NET WebAPI 2 este pornită într-un container docker.
Site-ul rădăcină este gol, iar subdirectorul „/myapp” conține aplicația web care rulează.
Pool-ul de aplicații este configurat să pornească automat și să rămână mereu activ. Setarea preloadEnabled este activă pentru a se asigura că reciclarea suprapusă are loc corect și Application_Start se finalizează înainte de a servi cererile. Am desemnat chiar și o pagină de încălzire care setează un semnalizare și am confirmat că este apelată și înainte ca un nou proces să primească cereri.
Problema pe care o am este că atunci când sarcina este plasată pentru prima dată, înainte ca Application_Start să fie apelată, văd jurnalele de sistem Windows care indică faptul că IIS crede că a avut loc o modificare de configurare care necesită o repornire a pool-ului de aplicații. Rezultatul este că un al doilea proces w3wp.exe începe să execute logica Application_Start la doar câteva secunde după începerea primului proces, înainte ca acesta să aibă șansa de a finaliza executarea Application_Start. În cele din urmă, ambele procese se blochează și sunt înlocuite cu un al treilea proces care se finalizează cu succes și începe să servească cererile.
Deci prima mea întrebare este, de ce un container docker proaspăt care este pe cale să pornească IIS s-ar gândi imediat că au avut loc unele modificări ale setărilor care necesită iniţială proces de reciclare? În momentul în care acest jurnal de sistem este scris, nici măcar nu a rulat niciun cod de utilizator; marca de timp apare cu câteva secunde înainte ca Application_Start chiar să înregistreze orice activitate. A doua mea întrebare este, cum aș putea să îmi dau seama ce declanșează această schimbare aparentă a setărilor sau ce este schimbarea setărilor? Jurnalul nu menționează ce setări sau fișier s-au schimbat sau de ce. Acest lucru pare deosebit de greu de depanat într-un container docker.
Din câte știu, există niciun scaner de viruși nu atinge fișierele în containerul docker (așa cum s-a sugerat inițial Aici), și din câte știu, sistemul de fișiere al unei imagini docker este deja blocat la pornire; nu este ca și cum liniile din fișierul docker care modifică setările sunt reluate atunci când imaginea este montată.
Jurnalele de sistem:
25.01.2022 22:36:59 Avertisment WAS Un proces care deservește pool-ul de aplicații „DefaultAppPool” sa încheiat în mod neașteptat. Id-ul procesului a fost „11592”. Codul de ieșire al procesului a fost „0xc0000005”.
25.01.2022 22:36:59 Avertisment WAS Un proces care deservește pool-ul de aplicații „DefaultAppPool” a suferit o eroare de comunicare fatală cu Serviciul de activare a procesului Windows. Id-ul procesului a fost „1328”. Câmpul de date conține numărul de eroare. 109 0 7 128
25.01.2022 22:34:35 Informații WAS Procesele de lucru care deservesc pool-ul de aplicații „DefaultAppPool” sunt reciclate din cauza uneia sau mai multor modificări de configurare în proprietățile pool-ului de aplicații care necesită o repornire a proceselor.
Rețineți că primul jurnal de la 22:34:35, care indică ceva schimbat, are loc ÎNAINTE ca primul proces să ajungă chiar la Application_Start, deoarece primul jurnal ieșit de Application_Start este marcat de timp după el. Comutarea diferitelor setări ale pool-ului de aplicații, cum ar fi timeout-urile de pornire și așa mai departe, modifică motivul pentru care cele două procese se blochează (de exemplu, uneori este o OutOfMemoryException în loc de o încălcare a accesului), dar nimic din toate acestea explică de ce consideră că este necesară o reciclare a pool-ului înainte de prima unul chiar începe și apoi începe două procese, unul aproape imediat după altul.Sunt mai puțin îngrijorat de motivul pentru care ambele se prăbușesc în cele din urmă și sunt apoi înlocuite cu un al treilea proces identic care se finalizează fără nicio problemă.
