Re: WebRequest problems

From: Jon Skeet [C# MVP] (skeet_at_pobox.com)
Date: 06/04/04 

Date: Fri, 4 Jun 2004 13:22:05 +0100

Michael Kremser <moc.NOTUSEABLE.unyd.taerg@nuj4002pxe> wrote:
> > Ah yes - for some reason it doesn't seem to implement IDisposable in
> > the Compact Framework. You need to call Close() on it, in a finally
> > block.
>
> I can't see it's implementing IDisposable at all, at least there's no
> method "Dispose" also in the "big" fx.

There's WebResponse.IDisposable.Dispose - it's done by explicit
interface implementation. If you look at "about WebResponse class"
you'll see it implements IDisposable.
 
> > That *should* fix the problem, I believe. (I had a very similar bug a
> > while ago.)
>
> I now close the stream as well as the response, as shown below:
>
> WebRequest req = WebRequest.Create(strURL);
> WebResponse resp = req.GetResponse();
> using (StreamReader reader = new StreamReader
> (resp.GetResponseStream(), System.Text.Encoding.UTF7))
> {
> strResult = reader.ReadToEnd();
> reader.Close();
> }
> resp.Close();
>
> ...but there's still the same error. :-( I begin to wonder whether we
> work with a beta release of CF... :-/

And are you always executing that Close()? Don't forget that the reader
could be throwing an exception. You don't need to call reader.Close(),
by the way - the using statement will call Dispose for you.

> However, in another thread on this NG I found a link where a download of
> a file is being described:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnne
> tcomp/html/AutoUpdater.asp
>
> I try this out and hope it helps. If not, I thought to just catch but
> ignore this exception (currently the user would get annoyed by a dialog
> box saying that the transfer failed - I will make a routine around the
> call that tries it maximum three times automatically if the problem
> persists).

I don't know whether doing things asynchronously will help - I believe
the problem is that there's a connection pool and if the responses
aren't being closed properly, those connections are all in use. Then
again, if resp.Close() *is* being executed in your code, that doesn't
account for the problem... 

-- 
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Relevant Pages

  • subject to Melves unconscious trend
    ... Where Dilbert's recent disappointment guarantees, ... They are executing on board top, in disciplinary, ... cover me celebrating in response to your thick post. ... Almost no apartments will be fatal confidential whales. ...
    (sci.crypt)
  • Re: Structured Exception Handling (was: Try Finally...)
    ... >statements will be traversed outwards exactly once, executing each ... What really bite me is the re-raise of the exception ... and the continuation in statementList2. ... This means that during unwinding the code immediately returns, ...
    (comp.lang.pascal.delphi.misc)
  • Re: HttpWebRequest.GetRequestStream times out
    ... When I encounter this exception, this is printed in the log: ... Stream sendStream = httpReq.GetRequestStream; ... you never read more than 1 kB of the response, ... The request timeout is set to 100 seconds, and the requests that time out ...
    (microsoft.public.dotnet.framework.performance)
  • Re: Cocoa Newbie Question.
    ...  Don't be surprised if executing the program appears to ... no response at all, since "test" is a shell builtin. ... on other people asking for help by ganging up with another poster to ...
    (comp.sys.mac.programmer.help)
  • Re: Why finally?
    ... I get the same results from executing the code as well. ... This seems to be a definite improvement of V1.x of the framework. ... normal exception paths. ... // Inject an asynchronous ThreadAbortException in the target thread, ...
    (microsoft.public.dotnet.languages.csharp)