[mark242]

"The asynchronous, non-blocking approach, is always wrong."

http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...

If you have a method that relies upon a DNS query, and your DNS server starts to respond to requests very slowly, your blocking application will run out of threads very quickly, and you'll be spending time poring over thread dumps trying desperately to see why all of your threads are waiting when the load average on your app server is basically zero. Your monitors will be going off like crazy because it appears that your application is flapping, sometimes able to handle a request and sometimes not. You will be tearing your hair out (and Java devs have all done this, though maybe not because of DNS).

If you have a non-blocking application, you will get an alarm that one of your pages may be acting a little slower than normal (even though the rest of your app is running normally). You'll look into the controller source, see that it's performing a DNS query, and poof, your debugging is done and you're off to restart bind.

[arielweisberg]

I think this is an argument for timeouts, fail over, and load shedding not asychrony.

If you have a sufficiently slow DNS you will chew through all the memory available to your non-blocking application in an amount of time that isn't functionally different from how long it will take you to exhaust your threadpool.

The whole point of the lightweight thread approach with shrinking stacks is that you will use the same amount of memory for both and they will fail at roughly the same point.

[pron]

You won't run out of (lightweight) threads because you can have millions of them. Blocking code on top of lightweight threads give you exactly the same scaling characteristics of nonblocking code.