Still seeing Thread blocked on DNS lookup (Vert.x 3.3.2)

[Arnaud Estève]

Hi everyone, I must be missing something but I'm still seeing the blocked thread checker yelling at me when doing server.listen(...)

Here's the stacktrace: 

AVERTISSEMENT: Thread Thread[vert.x-eventloop-thread-1,5,main] has been blocked for 2522 ms, time limit is 2000

io.vertx.core.VertxException: Thread blocked

at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)

at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)

at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)

at java.net.InetAddress.getLocalHost(InetAddress.java:1500)

at sun.management.VMManagementImpl.getVmId(VMManagementImpl.java:140)

at sun.management.RuntimeImpl.getName(RuntimeImpl.java:59)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at io.netty.channel.DefaultChannelId.defaultProcessId(DefaultChannelId.java:149)

at io.netty.channel.DefaultChannelId.<clinit>(DefaultChannelId.java:84)

at io.netty.channel.AbstractChannel.newId(AbstractChannel.java:105)

at io.netty.channel.AbstractChannel.<init>(AbstractChannel.java:77)

at io.netty.channel.nio.AbstractNioChannel.<init>(AbstractNioChannel.java:87)

at io.netty.channel.nio.AbstractNioMessageChannel.<init>(AbstractNioMessageChannel.java:42)

at io.netty.channel.socket.nio.NioDatagramChannel.<init>(NioDatagramChannel.java:146)

at io.netty.channel.socket.nio.NioDatagramChannel.<init>(NioDatagramChannel.java:114)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

at java.lang.reflect.Constructor.newInstance(Constructor.java:423)

at java.lang.Class.newInstance(Class.java:442)

at io.netty.channel.ReflectiveChannelFactory.newChannel(ReflectiveChannelFactory.java:38)

at io.netty.bootstrap.AbstractBootstrap.initAndRegister(AbstractBootstrap.java:318)

at io.netty.bootstrap.AbstractBootstrap.register(AbstractBootstrap.java:234)

at io.vertx.core.dns.impl.fix.DnsNameResolver.<init>(DnsNameResolver.java:188)

at io.vertx.core.dns.impl.fix.DnsNameResolverBuilder.build(DnsNameResolverBuilder.java:364)

at io.vertx.core.impl.AddressResolver$1.newResolver(AddressResolver.java:143)

at io.netty.resolver.AddressResolverGroup.getResolver(AddressResolverGroup.java:67)

at io.vertx.core.impl.AddressResolver.resolveHostname(AddressResolver.java:162)

at io.vertx.core.impl.VertxImpl.resolveAddress(VertxImpl.java:683)

at io.vertx.core.net.impl.AsyncResolveConnectHelper.doBind(AsyncResolveConnectHelper.java:74)

at io.vertx.core.http.impl.HttpServerImpl.listen(HttpServerImpl.java:256)

at io.vertx.core.http.impl.HttpServerImpl.listen(HttpServerImpl.java:191)

at com.decathlon.stores.indexing.api.RESTSearchServer.start(RESTSearchServer.java:60)

at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$8(DeploymentManager.java:434)

at io.vertx.core.impl.DeploymentManager$$Lambda$26/1684890795.handle(Unknown Source)

at io.vertx.core.impl.ContextImpl.lambda$wrapTask$3(ContextImpl.java:359)

at io.vertx.core.impl.ContextImpl$$Lambda$27/1150538133.run(Unknown Source)

at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:339)

at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:393)

at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742)

at java.lang.Thread.run(Thread.java:745)

I guess it was fixed, but maybe only for httpClient, not httpServer.

Thanks for any pointer, I may be missing something obvious :)

[Julien Viet]

Hi,

it has been fixed for the server as well but in this case this is not avoidable as it happens in the Java Management layer.

It seems to be done in the static initializer of Netty’s io.netty.channel.DefaultChannelID so it should happen once.

So overall I think it’s not really a problem as it would happen only once.

If you don’t want to avoid it and you are running this in a mail, you could preload it from Java’s main thread, perhaps using

DefaultChannelId.newInstance();

before using Vert.x

Julien

--
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.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/7d70394f-d8f4-41ff-b59a-fa7223fa0295%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.