DNS resolution failing with java.net.UnknownHostException

[Satyabrata Mishra]

Hello,

We are running a web application that uses Vert.x 4.5.14 along with Netty 4.1.118.Final. At times, when making a REST or AMQP call from our application, the DNS resolution fails with the following error:

`Caused by: io.netty.resolver.dns.DnsNameResolverException: [7982: /169.xxx.x.2:53] DefaultDnsQuestion(ccfc78d9-dfed-44c5-xxd5-e81xxxxxxx.xxxxxxx.eu20.ssb-live.live.mesxxxxxoker.net.xxx. IN A) failed to send a query '7982' via UDP (no stack trace available) 

Caused by: io.netty.channel.StacklessClosedChannelException at io.netty.channel.AbstractChannel$AbstractUnsafe.write(Object, ChannelPromise)(Unknown Source)

`

Once this issue occurs, it persists until the application is restarted. We were able to reproduce it under very high load by using Netty directly, but have not yet reproduced it when using Vert.x WebClient or the Proton client.

We are aware that we are currently using older versions of Vert.x and Netty. Could you confirm if this issue has been addressed in newer releases?

[Satyabrata Mishra]

Netty version is 4.1.119.Final.

[Thomas SEGISMONT]

Hi,

I had not seen this error before. Is it possible to reproduce on the dev machine?

As a workaround, you can switch to the JVM builtin DNS resolver with a sysprop:

-Dvertx.disableDnsResolver=true

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/vertx/91489f7c-8daa-468c-9d37-04f017674aa1n%40googlegroups.com.

[Satyabrata Mishra]

Hello Thomas,

Unfortunately, we were not able to reproduce it in the dev system using either of the vert.x webclient or proton client. 

Looks like the issue occurs when the UDP channel opened by netty's DNS resolver is closed, and the next DNS resolution query tries to write to the same channel.

Since we are not invoking any DNS resolution call explicitly from our application, we are assuming it is the web client that closes the channel.

`As a workaround, you can switch to the JVM builtin DNS resolver with a sysprop:`, will this cause any performance issues in the application? I guess the JVM builtin DNS resolver is bloacking in nature.

[Thomas SEGISMONT]

Le sam. 13 sept. 2025 à 19:19, Satyabrata Mishra <satya.m...@gmail.com> a écrit :

Hello Thomas,

Unfortunately, we were not able to reproduce it in the dev system using either of the vert.x webclient or proton client. 

Looks like the issue occurs when the UDP channel opened by netty's DNS resolver is closed, and the next DNS resolution query tries to write to the same channel.

Since we are not invoking any DNS resolution call explicitly from our application, we are assuming it is the web client that closes the channel.

`As a workaround, you can switch to the JVM builtin DNS resolver with a sysprop:`, will this cause any performance issues in the application? I guess the JVM builtin DNS resolver is bloacking in nature.

It may cost a bit more but this only happen once when the connection is created. In a pool of Http Client connections, long lived connections should be the norm

 

On Thursday, 11 September 2025 at 22:37:05 UTC+5:30 Thomas SEGISMONT wrote:

Hi,

I had not seen this error before. Is it possible to reproduce on the dev machine?

As a workaround, you can switch to the JVM builtin DNS resolver with a sysprop:

-Dvertx.disableDnsResolver=true

Le lun. 8 sept. 2025 à 13:32, Satyabrata Mishra <satya.m...@gmail.com> a écrit :

Netty version is 4.1.119.Final.

On Monday, 8 September 2025 at 16:53:33 UTC+5:30 Satyabrata Mishra wrote:

Hello,

We are running a web application that uses Vert.x 4.5.14 along with Netty 4.1.118.Final. At times, when making a REST or AMQP call from our application, the DNS resolution fails with the following error:

`Caused by: io.netty.resolver.dns.DnsNameResolverException: [7982: /169.xxx.x.2:53] DefaultDnsQuestion(ccfc78d9-dfed-44c5-xxd5-e81xxxxxxx.xxxxxxx.eu20.ssb-live.live.mesxxxxxoker.net.xxx. IN A) failed to send a query '7982' via UDP (no stack trace available) 

Caused by: io.netty.channel.StacklessClosedChannelException at io.netty.channel.AbstractChannel$AbstractUnsafe.write(Object, ChannelPromise)(Unknown Source)

`

Once this issue occurs, it persists until the application is restarted. We were able to reproduce it under very high load by using Netty directly, but have not yet reproduced it when using Vert.x WebClient or the Proton client.

We are aware that we are currently using older versions of Vert.x and Netty. Could you confirm if this issue has been addressed in newer releases?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/vertx/91489f7c-8daa-468c-9d37-04f017674aa1n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/vertx/a59b9501-bbb1-4ee4-b87a-adce695b5297n%40googlegroups.com.