BrightSoul ha scritto:
Esistono anche deadlock causati dal codice:
http://www.c-sharpcorner.com/UploadFile/1d42da/deadlock-in-threading-in-C-Sharp/
http://nikgupta.net/2014/06/20/deadlocks-when-using-tasks/
http://nikgupta.net/2014/07/02/configureawait-solves-deadlocks-when-using-tasks/
Non sono del tutto convinto che il problema sia il BasicHttpsBinding, almeno non direttamente, anche se così sembra. È impossibile per me sapere come intervenire dato che non hai fornito un progetto di esempio in cui si possa osservare il problema.
Come posso indagare su IIS per capire dove si blocca, o la causa della mancata risposta ?
Nella tua applicazione, vai nel metodo che sta causando il blocco, scrivi delle righe di log frequenti. Quando l'applicazione si blocca, vai a vedere cosa c'è nel log così riuscirai a capire qual è l'ultima istruzione eseguita. Quella successiva è quella che sta causando il blocco.
ciao,
Moreno
Va bene Moreno, studierò i link proposti. Per quanto riguarda il tuo consiglio ho già eseguito il debug passo passo lato server e quando si blocca infatti mi dice che è in attesa da una risposta esterna che non dipende dall'ambiente .NET. Qualcosa del tipo "non c'è nessun codice in esecuzione in .NET ...".
Sto pensando di fare la prova su un altra macchina installata di sana pianta con IIS e vedere se il problema si riproduce anche lì.
La mia impressione (ma può darsi che sbagli) è che abbia a che fare con la cache, per cui dopo un certo numero di "scambi" questa si riempia. Infatti a causa della codifica supplementare il lavoro che deve fare è maggiore.
Dico ciò perchè quando si blocca e vado nel pannello di IIS e cerco di arrestarlo, perde anche 1 minuto per fermarsi, mentre in condizione normali il sito si arresta nel giro di 1 o max 2 secondi.
Era questo il motivo per cui volevo esaminare i registri di IIS, sono sicuro che c'è un bug lì.
Infine non ho potuto allegare il progetto, perchè il livello di complessità è elevato con un'interazione massiccia fra almeno tre componenti che dovrebbero essere riprodotti, ovvero Il Client che invia le richieste di lettura, il server che le elabora provvedendo ad eseguire le altre operazioni di contorno (ho provato anche a scollegare alcune di queste operazioni corollario), ed il DB, oggetto delle richieste e che resituisce i dati da diverse tabelle. Dato che sono solo letture non ci sono transaction coinvolte.
Ridurre il tutto, semplificandolo ad una richiesta server/DB, potrebbe anche non saturare mai la banda e portare all'errore.
Per questo volevo operare a livello di IIS, vorrei un log dettagliato delle operazioni che compie, per capire dove si blocca, dato che nell'applicazione nn c'è nessun blocco (almeno è questo che dice Visual Studio).
Grazie Moreno.
Gino.
Modificato da SensoBit il 07 marzo 2018 08.18 -
