#ryadelwebclient

Oggi mi è toccato risolvere uno strano problema di timeout che si è verificato improvvisamente a una delle mie applicazioni Web ASP.NET: quando ho guardato i log, ho capito facilmente che il timeout era causato da una richiesta HTTP emessa da un'istanza della classe System.Net.WebClient che non riusciva a connettersi a un servizio web di terze parti, il quale risultava temporaneamente non disponibile. Ecco l'errore generato dall'oggetto WebClient: System.Net.Sockets.SocketException: Impossibile stabilire la connessione. Risposta non corretta della parte connessa dopo l'intervallo di tempo oppure mancata risposta dall'host collegato 216.239.38.21:443 (server ip address). E questo è lo snippet di codice che lo generava: Ovviamente la chiamata di cui sopra si trovava all'interno di un blocco try / catch, che impediva all'applicazione web di andare in errore; al tempo stesso, però, l'impossibilità di effettuare la connessione provocava un timeout non indifferente, pari al timeout predefinito della classe WebClient... ovvero, 100.000 millisecondi (!), senza peraltro alcun modo di cambiarlo (!!) visto che l'oggetto WebRequest sottostante utilizzato per effettuare la richiesta web viene creato on-the-fly e quindi non esposto (!!!). Non male come situazione, vero? Fortunatamente, dopo una breve ricerca su Google, ho trovato un thread su StackOverflow che mi ha consentito di gestire la situazione nel migliore dei modi. Read the full article

Today I had to fix an odd timeout issue that suddenly occurred to  one of my ASP.NET web applications: when I looked at the logs, I easily figured out that the timeout was caused by a HTTP request issued by a System.Net.WebClient instance that couldn't retrieve some data from an external website which was down. Here was the actual error raised from the WebClient: System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond (server ip address). And here's the code snippet that triggered it: Needless to say, I had wrapped the call inside a try/catch block, therefore I "just" had to deal with the WebClient timeout... which sadly happens to be hard-coded to 100.000 milliseconds (!), with no way to change it (!!), as the underlying WebRequest object used to estabilish the connection is not exposed by the "wrapper" class (!!!). Not bad, right? Luckily enough, I googled around and quickly found a neat way to handle such situation on the StackOverflow web site. Read the full article