62 messaggi dal 01 febbraio 2017
Salve, ho un problema su cui mi sto arrovallando da un pò di tempo.
COROLLARIO
Ho effettuato al trasformazione di un vecchio servizio funzionante con Web service (WS.ASMX) in WCF, e con pochissime modifiche al codice, ha funzionato tutto perfettamente.

Il servizio è consumato da un'applicazione (Win form) .

A questo punto ho aumentato il livello di sicurezza, implemetanto WsHttpBinding, invece del vecchio (ed interoperabile) BasicHttpBinding.

e qui è sorto il problema.

PROBLEMA

L'applicazione client funziona bene anche nella nuova versione, ma saltuarialmente si blocca.
Dopo diverse prove ho individuato il problema. L'applicazione usa una funzione di scorrimento su un archivio (record precedente/record successivo), e ad ogni lettura effettua una serie di chiamate al servizio per la decodifica di altri campi.
Bene, anzi male, dopo un certo numero di click su PRECEDENTE (ma anche SUCCESSIVO) l'applicazione client si blocca per un tempo indefinito.

Cambiando solamente il binding, e rimettendo (ovviamnete sia sul client che sul servizio) BasicHttpBinding, il tutto torna a funziare senza blocchi. Mentre invece inserendo WSHttpBinding riprende il blocco, quindi senza toccare il codcie, ma solo il WEB.CONFIG E APP.CONFIG.

PROVE
Ho provato col debug a capire quale fosse l'istruzione del servizio che la bloccasse, poichè risultava che il client era in attesa di risposta da parte del servizio. Ma l'IDE mi segnala che il servizio è fermo su una istruzione in attesa del CLR, ovvero il blocco è nell'ambiente runtime.

Uno sniffer del traffico, mi fa vedere la richiesta del client con la sua intestazione, ma risulta che non arriva nessuna risposta. La CPU d'altronde non è alluppata .... il pc risponde normalmente ...

Idee ? Consigli ?

Come posso indagare più approfonditamente su tale problema ? Come posso capire perchè il CLR si pianta senza nessun messaggio ?

L'unica cosa che capisco è che con wsHttp entra in gioco la codifica dei dati, a tal fine, ho provveduto a disattivare la mia codifica personalizzata che avevo inserito nel vecchio servizio WS.ASMX, pensando magari che la doppia criptazione andasse in conflitto, ma nulla è cambiato; si pianta miseramente, senza nessun messaggio.

Idee, consigli ?

Grazie.
Gino.
11.097 messaggi dal 09 febbraio 2002
Contributi
Ciao Gino, non so con sicurezza quale possa essere la causa. Dato che la CPU non è al 100%, potrebbe trattarsi di un deadlock a livello del db. Oppure, se stai usando operazioni asincrone, magari devi aggiungere un .ConfigureAwait(false) come spiegato qui:
https://medium.com/bynder-tech/c-why-you-should-use-configureawait-false-in-your-library-code-d7837dce3d7f

Inoltre, hai provato a vedere se il problema ti si verifica anche con operazioni molto semplici, tipo che restituiscono una banale stringa (senza accedere al db o altro). In caso scriviti quest'operazione e fai delle prove, così cominciamo ad escludere qualche causa.

ciao,
Moreno
Modificato da BrightSoul il 27 novembre 2017 13.11 -

Enjoy learning and just keep making
62 messaggi dal 01 febbraio 2017
Ciao Moreno, speravo in tuo intervento.

Si il servizio usa operazioni asincrone, nel senso che ho spuntato la casella "genera operazioni asincrone" nel riferimento al servizio (nel Client). Ma poi mi limito ad usare la sua versione customizzata dalla classe proxy che ha generato VS.
Quindi il metodo "Leggi_successivo" diventa "Leggi_successivoAsync" e nel codice non uso il costrutto ASYNC/AWAIT.
Il risultato viene poi accolto nell'evento "Leggi_successivoComplete", svincolamdomi dalla relativa gestione dei delegati.

Quindi anche volendo dove dovrei settare un .ConfigureAwait(false) ?
Forse è usato nella classe proxy generata dal compilatore ?

Come dicevo tutto funziona bene, anche con WCF ed anche con accessi multipli sul db, e questo è vero fin quando uso il BasicHttpBindig.

Si "rompono i telefoni", appena uso wsHttpBinding. Quindi se fosse un problema di accesso concorrenziale al DB che blocca qualcosa, lo dovrebbe fare anche con basicHttpBinding ?

C'è qualche modo/strumento che mi possa aiutare a capire dove è bloccato l'ambiente runtime ? Ho visto che VS 2015, mette a disposizione molti strumenti di indagine.

Grazie.
Gino.
62 messaggi dal 01 febbraio 2017
Aggiungo che da altre prove fatte, vedo IIS bloccato, nel senso che appena tento di riavviarlo anche solo arretsarlo (quando succede il problema), non risponde per un bel pò di tempo.

Cosa potrebbe essere ?
62 messaggi dal 01 febbraio 2017
Aggiornamento

Dopo diversi giorni di prove e ricerche ho trovato questo articolo :
https://support.microsoft.com/en-us/help/2870705/iis-7-5-or-iis-8-0-process-crashes-in-windows

Il problema sembra essere un bug di IE da win 7 in poi e suggeriscono la hotfix, da richiedere privatamente.

Ma dato le cautele da cui è accompagnata, prima di provare anche questa volevo capire meglio.

Il contesto a cui è riferito questo blocco di 2000 identità a cosa è riferito ?
Applicando il bug al WCF da cui sono partito, il SendResponse di cui parla l'articolo è riferito alla richiesta del client o a quella del server ?

Non ci sto capendo più nulla.

Grazie.

Gino.
62 messaggi dal 01 febbraio 2017
E rieccomi, dopo aver accantonato il progetto per altre scadenze più urgenti, con la speranza di nn fare la particella di sodio ... non, non la faccio la domanda fatidica ... eheheh ...

Ordunque dicevo, nelle more di riuscire a capire perchè ISS si blocca, ho provato a guardare nei registri del server, ma nulla, ho provato ad attivare il log autonomo (da IIS) direttamente sul sito in questione, ma neanche lì spunta nulla.

Ho provato a intercettare il traffico con Fiddler, e si vedono le richeste inviate dal client e le risposte di IIS, fino all'ultima che rimane senza risposta da parte di IIS (ed è quando il CLR si blocca).

Ho provato infine ad abilitare il debug a livello di web.config, ma neanche così mi esce nulla. La tecnologia WEB non è il mio forte, mi sono sempre dedicato alla programmazione ad altri livelli, assembler, C, RPG e Cobol, in ambiente mainframe IBM.

Qualche anima pia che può darmi uno spunto per uscire dall'empasse ?

Grazie.
11.097 messaggi dal 09 febbraio 2002
Contributi
Ciao,
continuo a pensare che ci sia un deadlock da qualche parte ma non ho idea dove. Via forum non ne siamo venuti a capo, hai bisogno che un consulente venga lì ed esamini il codice per qualche ora per scoprire dov'è il problema.

ciao,
Moreno

Enjoy learning and just keep making
62 messaggi dal 01 febbraio 2017
Ciao Moreno, il debug da Visual Studio dice che il CLR è bloccato in attesa di risposta.
Fiddler invia la richiesta e IIS risponde, fino all'ultima richiesta a cui nn segue risposta da parte di IIS.

Infine cambiando solamnte il web.config nel Server, e il APP.config nel client mettendo le versioni con basicHttpBindig il tutto torna a funzionare senza blocchi.

Se fosse un deadlock sul db, dovrebbe bloccarsi lo stesso.

Come posso indagare su IIS per capire dove si blocca, o la causa della mancata risposta ?

Grazie.

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.