Enabling Micrometer metrics while using a UNIX native domain socket causes NPE

[Stimzz]

Questions

If having enabled MicrometerMetrics while connecting to an UNIX native domain socket it result in an NPE when io.vertx.core.net.impl.SocketAddressImpl is instantiated. The SocketAddress is instantiated with a port, host constructor but the host argument is null and it has a require not null check in the constructor.

The issue can be avoided by turning off Micrometer but a more precise solution is to disable NET_CLIENT Metrics domain.

The stack trace:
java.lang.NullPointerException: no null host accepted at java.util.Objects.requireNonNull(Objects.java:247) ~[?:?] at io.vertx.core.net.impl.SocketAddressImpl.<init>(SocketAddressImpl.java:30) ~[vertx-core-3.9.2.jar:3.9.2] at io.vertx.micrometer.impl.VertxNetClientMetrics$Instance.connected(VertxNetClientMetrics.java:65) ~[vertx-micrometer-metrics-3.9.2.jar:3.9.2] at io.vertx.micrometer.impl.VertxNetClientMetrics$Instance.connected(VertxNetClientMetrics.java:56) ~[vertx-micrometer-metrics-3.9.2.jar:3.9.2] at io.vertx.core.net.impl.NetClientImpl.lambda$null$5(NetClientImpl.java:223) ~[vertx-core-3.9.2.jar:3.9.2] at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:366) ~[vertx-core-3.9.2.jar:3.9.2] at io.vertx.core.impl.EventLoopContext.execute(EventLoopContext.java:43) ~[vertx-core-3.9.2.jar:3.9.2] at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:229) ~[vertx-core-3.9.2.jar:3.9.2] at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:221) ~[vertx-core-3.9.2.jar:3.9.2] at io.vertx.core.net.impl.NetClientImpl.lambda$connected$6(NetClientImpl.java:221) ~[vertx-core-3.9.2.jar:3.9.2] at io.vertx.core.net.impl.VertxHandler.setConnection(VertxHandler.java:85) ~[vertx-core-3.9.2.jar:3.9.2] at io.vertx.core.net.impl.VertxHandler.handlerAdded(VertxHandler.java:102) ~[vertx-core-3.9.2.jar:3.9.2] at io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:938) ~[netty-transport-4.1.51.Final.jar:4.1.51.Final] at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609) ~[netty-transport-4.1.51.Final.jar:4.1.51.Final] at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:223) ~[netty-transport-4.1.51.Final.jar:4.1.51.Final] at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:195) ~[netty-transport-4.1.51.Final.jar:4.1.51.Final] at io.vertx.core.net.impl.NetClientImpl.connected(NetClientImpl.java:232) ~[vertx-core-3.9.2.jar:3.9.2] at io.vertx.core.net.impl.NetClientImpl.lambda$doConnect$3(NetClientImpl.java:187) ~[vertx-core-3.9.2.jar:3.9.2] at io.vertx.core.net.impl.ChannelProvider.lambda$connect$1(ChannelProvider.java:78) ~[vertx-core-3.9.2.jar:3.9.2] at io.vertx.core.net.impl.ChannelProvider.connected(ChannelProvider.java:160) ~[vertx-core-3.9.2.jar:3.9.2] at io.vertx.core.net.impl.ChannelProvider.lambda$handleConnect$2(ChannelProvider.java:143) ~[vertx-core-3.9.2.jar:3.9.2] at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:577) ~[netty-common-4.1.51.Final.jar:4.1.51.Final] at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:551) ~[netty-common-4.1.51.Final.jar:4.1.51.Final] at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:490) ~[netty-common-4.1.51.Final.jar:4.1.51.Final] at io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:615) ~[netty-common-4.1.51.Final.jar:4.1.51.Final] at io.netty.util.concurrent.DefaultPromise.setSuccess0(DefaultPromise.java:604) ~[netty-common-4.1.51.Final.jar:4.1.51.Final] at io.netty.util.concurrent.DefaultPromise.trySuccess(DefaultPromise.java:104) ~[netty-common-4.1.51.Final.jar:4.1.51.Final] at io.netty.channel.DefaultChannelPromise.trySuccess(DefaultChannelPromise.java:84) ~[netty-transport-4.1.51.Final.jar:4.1.51.Final] at io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe.fulfillConnectPromise(AbstractEpollChannel.java:615) ~[netty-transport-native-epoll-4.1.51.Final-linux-x86_64.jar:4.1.51.Final] at io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe.connect(AbstractEpollChannel.java:563) ~[netty-transport-native-epoll-4.1.51.Final-linux-x86_64.jar:4.1.51.Final] at io.netty.channel.DefaultChannelPipeline$HeadContext.connect(DefaultChannelPipeline.java:1342) ~[netty-transport-4.1.51.Final.jar:4.1.51.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:548) ~[netty-transport-4.1.51.Final.jar:4.1.51.Final] at io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:533) ~[netty-transport-4.1.51.Final.jar:4.1.51.Final] at io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:517) ~[netty-transport-4.1.51.Final.jar:4.1.51.Final] at io.netty.channel.DefaultChannelPipeline.connect(DefaultChannelPipeline.java:978) ~[netty-transport-4.1.51.Final.jar:4.1.51.Final] at io.netty.channel.AbstractChannel.connect(AbstractChannel.java:253) ~[netty-transport-4.1.51.Final.jar:4.1.51.Final] at io.netty.bootstrap.Bootstrap$3.run(Bootstrap.java:250) ~[netty-transport-4.1.51.Final.jar:4.1.51.Final] at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164) ~[netty-common-4.1.51.Final.jar:4.1.51.Final] at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472) ~[netty-common-4.1.51.Final.jar:4.1.51.Final] at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:387) ~[netty-transport-native-epoll-4.1.51.Final-linux-x86_64.jar:4.1.51.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) ~[netty-common-4.1.51.Final.jar:4.1.51.Final] at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.51.Final.jar:4.1.51.Final] at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[netty-common-4.1.51.Final.jar:4.1.51.Final] at java.lang.Thread.run(Thread.java:830) [?:?]

Version

3.9.2 (and all down to 3.9.0). Haven't tested 3.8.X because the Redis client that we use for the native socket was added in 3.9.

Context

I ran into the issue when combining the Vertex Redis client to connect via UNIX domain socket while having Vertx Micrometer active.

Do you have a reproducer?

https://github.com/Stimzz/vertx-metrics-native-socket-reproducer

Run the unit test and the test will crash with NPE. Uncomment the .addDisabledMetricsCategory(MetricsDomain.NET_CLIENT) line in the test when setting MetricsOptions and the case will succeed (to prevent Micrometer client from attempting to log the connection event on the domain socket).

The unit test just use the the NetClient directly on a domain socket. We initially discovered this when using the Redis client but this works as well more directly.

Steps to reproduce

1. Activate Vertx micrometer
2. Activate native transport and attempt connecting to a UNIX domain socket. The connection will throw a NPE.

Extra

Observed on Ubuntu 18.04 and 20.04 both running Adoptopenjdk 13 hotspot.

[tsegismont]

@jotak can you look into this? Is this specific to the Micrometer implementation or a more generic problem when domain sockets are used?

[jotak]

Yes I confirm, bug spotted on our micrometer impl side, we are indeed assuming inet address with host & port