async-http-client icon indicating copy to clipboard operation
async-http-client copied to clipboard

DNS lookups should not block the event loop

Open n-miles opened this issue 5 years ago • 9 comments

The Problem

The default name resolver for AHC is:

new DefaultNameResolver(ImmediateEventExecutor.INSTANCE)

This does DNS lookups by using the calling thread (a Netty event loop thread) to do a blocking DNS lookup via the OS mechanism. This is a bad default behavior.

Proposed Solution

I propose that we move the blocking DNS lookups into a separate event loop. There does not appear to be a resolver in Netty that will do this, so we would likely need to create one.

Thoughts?

I am willing to do the development for this if we want this feature.

n-miles avatar May 09 '20 00:05 n-miles

@n-miles if this is still relevant, I contacted the repo's maintainer to take over the repo (he's been looking for a new maintainer for a while now).

If I get the green light I'd be happy to incorporate this feature into the project.

TomGranot avatar Aug 23 '20 19:08 TomGranot

@n-miles Current maintainer. If you'd like we can further discuss this - a proper spec is in order. Let me know if this is still relevant and we can develop the idea further (I don't see why allowing for less blocking is a bad idea, but would have to dig deeper to give a smarter answer).

TomGranot avatar Dec 12 '20 20:12 TomGranot

Hi,

This is very much still relevant. As of now, only the AWS http client does async dns resolution afaik. As with all async, such a change requires handling timeouts properly: the dns resolution process should be under the request timeout.

Having blocking code prevents decent scalability and creates weird thread starvation issues that are not worth fighting.

ghost avatar May 04 '21 06:05 ghost

The main issue with doing this is that there just isn't a mechanism in Java to do async lookups. Netty has resolvers that will hit DNS servers in an async fashion, but presumably most users want to use the normal OS mechanism. The closest approximation I can come up with is a threadpool doing blocking DNS lookups and just not blocking the calling (Netty) threads.

n-miles avatar May 04 '21 18:05 n-miles

The .net guys are doing async dns resolution on linux and windows, so the api is probably there.

On Tue, May 4, 2021, 20:34 Nathan Miles @.***> wrote:

The main issue with doing this is that there just isn't a mechanism in Java to do async lookups. Netty has resolvers that will hit DNS servers in an async fashion, but presumably most users want to use the normal OS mechanism. The closest approximation I can come up with is a threadpool doing blocking DNS lookups and just not blocking the calling (Netty) threads.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/AsyncHttpClient/async-http-client/issues/1724#issuecomment-832155881, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJF5YQOSQ4WK4ARC7SXZWDDTMA42TANCNFSM4M4RWOOA .

ghost avatar May 04 '21 18:05 ghost

The APIs are there in Linux and Windows at the OS layer, yes. But I don't believe those APIs exist on all OSes that Java supports, so there is not a mechanism to do that in Java.

n-miles avatar May 05 '21 15:05 n-miles

Might not be, but some ways to make this possible, best effort style, is valuable.

ghost avatar May 05 '21 15:05 ghost

If you figure out how to do non-blocking DNS lookups using the OS mechanism on the JVM please tell me how you did it

n-miles avatar May 05 '21 19:05 n-miles

Don't get your hopes up; i/m borderline giving up on building web servers on the jvm due to such issues; just too much hassle.

I'm on micronaut which uses netty under the hood, which ca do async dns across the jvm/linux os i care ab (which are always the latest); hopefully that is easier to implement.

Thanks for looking into this.

ghost avatar May 05 '21 19:05 ghost