Prev: ASPNET credentials keep on resetting
Next: remoting is knocking down CPU
From: Malcolm Hall on 21 Nov 2009 15:25
The hang happens at BeginGetRequestStream. It must be my ISP cause I
had some other people try the ping test and theirs fails almost
instantly like you. I thought the whole point of the async methods is
to make it easier to have a responsive UI and not have the complexity
of creating threads but that all goes out the window beacuse of this
case. So I guess I have 2 choices:

1. Do my own DNS resolve in a thread and then invoke the UI thread and
replace the domain name with the IP in the async request if it is
valid.
2. Resort to using the Background Worker or Async Operation classes
and use the async web req methods in sync (you know the pattern when
you do waitone on the async handle so you can still abort)...

Actually has anyone seen a good async Http Post class with events?
That's all I really need.
From: Malcolm Hall on 21 Nov 2009 15:34
Now we know the method causing the problem I found this post on the
topic:

http://stackoverflow.com/questions/1232139/webrequest-begingetresponse-is-taking-too-much-time-when-the-url-is-invalid
From: Malcolm Hall on 21 Nov 2009 15:56
Durgaprasad Gorti @ http://social.msdn.microsoft.com/forums/en-US/netfxnetcom/thread/2cb74a7e-6e8f-4d05-b86a-2401df5d2ed3/

"You are absolutely correct. If you call the BeginGetResponse(), today
we block until the
name resolution happens. This is result of an unfortunate series of
issues we had to
workthrough in the initial release and we were locked into backward
compatibility for the
2.0 release.

We are considering this to be one of the important issues to fix in a
future release.
Sorry for the inconvinience caused. Let me know if there is anything
else I can help you with"

Sept 2006!!! Guess it wasn't important enough then :-(
From: Peter Duniho on 21 Nov 2009 16:04
Goran Sliskovic wrote:
>
> "Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> wrote in message
> news:OIAIG5taKHA.5608(a)TK2MSFTNGP05.phx.gbl...
> ....
>> Well, like I said, I was unable to reproduce the problem. In fact, I
>> did the same kind of timing modification to the code example when I
>> original tested it, and while the call to UploadStringAsync() took
>> almost all of the total execution time, it was generally less than
>> 100ms to return.
>>
> ....
>
> You have to test probably with non-existant DNS server, not non-existant
> domain. [...]

No. I have to test using the same scenario that the OP is using. The
point is to try to achieve results comparable to his, not necessarily to
find _another way_ to force a delay in DNS resolution.

Pete
From: Peter Duniho on 21 Nov 2009 16:12
Malcolm Hall wrote:
> Durgaprasad Gorti @ http://social.msdn.microsoft.com/forums/en-US/netfxnetcom/thread/2cb74a7e-6e8f-4d05-b86a-2401df5d2ed3/
>
> "You are absolutely correct. If you call the BeginGetResponse(), today
> we block until the
> name resolution happens. This is result of an unfortunate series of
> issues we had to
> workthrough in the initial release and we were locked into backward
> compatibility for the
> 2.0 release.
>
> We are considering this to be one of the important issues to fix in a
> future release.
> Sorry for the inconvinience caused. Let me know if there is anything
> else I can help you with"
>
> Sept 2006!!! Guess it wasn't important enough then :-(

Have you tried it in the .NET 4.0 beta? Maybe it has been fixed, finally.

There is, of course, the issue that just because Durgaprasad Gorti
considered it an important issue in 2006, that doesn't mean he even
still works in that group, never mind still considers it important.

A much better way to state your case and provide for a way to track
progress of the bug resolution is to submit a report on the Connect web
site. Then you can see the official response, as well as have others
provide feedback regarding importance and workarounds.

As far as workarounds go, you have lots of options, not just the two you
mentioned. But yes, wrapping a synchronous call in an asynchronous
operation is a tried-and-true way of dealing with this sort of thing.
If you're dealing with a GUI and really need the completion to be
signaled on the main GUI thread, BackgroundWorker is the way to go.
Otherwise, a simple asynchronous delegate invocation might be fine.

Pete
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: ASPNET credentials keep on resetting
Next: remoting is knocking down CPU