Prev: ASPNET credentials keep on resetting
Next: remoting is knocking down CPU
From: Goran Sliskovic on 21 Nov 2009 18:35

"Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> wrote in message
....
>> 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

We have first to make sure that delay in DNS resolution causes the problem.
You are not going to reproduce that if you DNS server is properly
configured.

Goran

From: Goran Sliskovic on 21 Nov 2009 18:46

"Malcolm Hall" <malcolm.hall(a)gmail.com> wrote in message
news:6c626391-3892-43b9-8d2c-0aec4e51df02(a)v30g2000yqm.googlegroups.com...
> 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.

You can verify that the problem is in DNS by using network protocol analyzer
such as wireshark (free).
Most likely it is the problem with DNS. Try to resolve name in command
prompt using nslookup and see what happens. I guess it will block for some
time on your system, it doesn't on my.
Your ideas will probably work.
It looks like a bug in the .NET framework to me. I expect async method to
queue the request and return immediatly. Though you can always stretch the
meaning of the work "immediately".

Goran



From: Peter Duniho on 21 Nov 2009 19:28
Goran Sliskovic wrote:
>
> "Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> wrote in message
> ....
>>> 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
>
> We have first to make sure that delay in DNS resolution causes the
> problem.

YOU may want to make sure of that. Please feel free to if you like.
But I have no need or desire to, and telling me that _I_ need to do that
is simply incorrect.

The point of my test is to try to reproduce the problem the OP is
having. Not to prove or disprove the plausibility of some theory.

If you make an assumption about the cause of the problem, and then
design your test to only succeed when your assumption is true, you
haven't demonstrated anything useful except that your theory _could_ be
correct. It doesn't say anything about whether it _is_ correct.

> You are not going to reproduce that if you DNS server is
> properly configured.

That all depends on what the actual problem is. My goal was simply to
determine whether or not, on my computer, the exact code that the OP
posted (or something very similar to it) causes the exact problem that
the OP is asking about.

I've done exactly that. Nothing more, nothing less.

Pete
From: Goran Sliskovic on 22 Nov 2009 14:14

"Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> wrote in message
news:eH$XrqwaKHA.4688(a)TK2MSFTNGP06.phx.gbl...
> Goran Sliskovic wrote:
>>
....
>
> I've done exactly that. Nothing more, nothing less.
>
> Pete

Whatever... However from what you did we know exactly what we knew before,
that we know nothing. This is a newsgroup where we try to help somebody.
It's not about theory, it's about practice.

Regards,
Goran



From: Malcolm Hall on 14 Dec 2009 18:38
I have found an easy work around until MS fix this:

This is an excerpt from: http://www.informit.com/blogs/blog.aspx?uk=Is-this-really-asynchronous

"There is a way around the problem: queue a background thread to issue
the asynchronous request. Yes, I know it sounds crazy, but it works.
And it's incredibly easy to do with anonymous delegates:

ThreadPool.QueueUserWorkItem(delegate(object state)
{
cli.DownloadStringAsync((Uri)state);
}, GetNextUrlFromQueue());

That spawns a thread, which then issues the asynchronous Web request.
The time waiting for DNS lookup is spent in the background thread
rather than on the main processing thread. It looks pretty goofy, and
unless it's commented well somebody six months from now will wonder
what I was smoking when I wrote it."
First  |  Prev  | 
Pages: 1 2 3
Prev: ASPNET credentials keep on resetting
Next: remoting is knocking down CPU