Getting more info from WebException when Status is Unknown Error

  • Thread starter Thread starter Greg
  • Start date Start date
G

Greg

My app makes a call to a remote server (about which I know relatively
little) using Webclient.DownloadData. This is done once every 51/2 mins
and is called by code within a worker thread. 95% of the time this
works ok and I get a sane response from the server. However, every
night within the same broad time window of 7 hours, I get a relatively
high incidence of WebException's being thrown. The status of this is
"UnknownError". When I try to log the response, i.e. printing out
repsonse.ToString() my error handler throws another exception. I can
only presume this is because response == null. (I am now testing
against response == null). So, where do I start looking for the source
of the error? Under what circumsances will WebClient behave like this?
Will a garbled response from the remote server cause this? I've tried
using a packet sniffer, though the one that I was using HTTPlook
trashed my program and I understand that this is a common problem. Are
there any tried, tested and very reliable packet sniffers out there
that I can use to help me work out what is going on? Anything else I
should look into within my app? There is a limit to how much logging
that can be done on the webserver that I am connecting to; the owners
are doing as much as they can to help.

Is there any significance in the fact that the code that does the
request is on a worker thread? I only mentioned it incase. I'm new to
multithreading and so am not too sure about what sort of things can go
wrong, but one of my coworkers who is well experienced is confident
that it isn't a threading issue.

This has been going on now for about 2 weeks and every nights testing
when I get unhelpful error information is another day lost. So, any
comments / suggestions would be very gratefully received.

Thanks,

Greg.
 
Thus wrote Greg,
My app makes a call to a remote server (about which I know relatively
little) using Webclient.DownloadData. This is done once every 51/2
mins and is called by code within a worker thread. 95% of the time
this works ok and I get a sane response from the server. However,
every night within the same broad time window of 7 hours, I get a
relatively high incidence of WebException's being thrown. The status
of this is "UnknownError". When I try to log the response, i.e.
printing out repsonse.ToString() my error handler throws another
exception. I can only presume this is because response == null. (I am
now testing against response == null).
Click to expand...

WebException.Response will only be valid if there's the exceptions' Status
is set to ProtocolError (i.e. a low level, non HTTP error).
So, where do I start looking
for the source of the error? Under what circumsances will WebClient
behave like this? Will a garbled response from the remote server cause
this? I've tried using a packet sniffer, though the one that I was
using HTTPlook trashed my program and I understand that this is a
common problem. Are there any tried, tested and very reliable packet
sniffers out there that I can use to help me work out what is going
on? Anything else I should look into within my app? There is a limit
to how much logging that can be done on the webserver that I am
connecting to; the owners are doing as much as they can to help.
Click to expand...

Ethereal with WinPcap is probably the most popular packet sniffer. You could
also try System.Net's built-in tracing functionality. See this blog entry
for more details: http://blogs.msdn.com/dgorti/archive/2005/09/18/471003.aspx
Is there any significance in the fact that the code that does the
request is on a worker thread? I only mentioned it incase. I'm new to
multithreading and so am not too sure about what sort of things can go
wrong, but one of my coworkers who is well experienced is confident
that it isn't a threading issue.
Click to expand...

As long as you use don't manipulate your WebClient instance(s) from multiple
threads without synchronization, you should be OK.

Cheers,
 
Back
Top