bind takes 5 seconds on osx, maybe related to logback-classic version

I’m running into some weird interaction between logback-classic and netty which is cause netty to take 5 seconds extra to bind when using a version of logback-classic equal to or higher than 1.1.10.

The difference in time taken is always 5 seconds and feels like some sort of sleep …

Unfortunately I’m not familiar enough with either project to figure out why… 😕
5000 does appear multiple times in the logback code: https://github.com/qos-ch/logback/search?q=5000&unscoped_q=5000

Expected behavior

bind to take ~50ms.

Actual behavior

bind takes ~5000ms.

Steps to reproduce

Running the code snippet below with logback-classic set to a version 1.1.10 or higher.

Minimal yet complete reproducer code (or URL to code)

/*
 * Copyright 2013 The Netty Project
 *
 * The Netty Project licenses this file to you under the Apache License,
 * version 2.0 (the "License"); you may not use this file except in compliance
 * with the License. You may obtain a copy of the License at:
 *
 *   http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
 * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
 * License for the specific language governing permissions and limitations
 * under the License.
 */
package io.netty.example.slow;

import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.EventLoopGroup;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioServerSocketChannel;
import java.io.IOException;
import java.net.InetSocketAddress;

import org.slf4j.LoggerFactory;
import org.slf4j.Logger;

/**
 * Sends one message to a serial device
 */
public final class Slow {
  private static final Logger logger = LoggerFactory.getLogger(Slow.class.getName());

  public static void main(String[] args) throws Exception {
    EventLoopGroup group = new NioEventLoopGroup();

    try {
      ServerBootstrap serverBootstrap = new ServerBootstrap();
      serverBootstrap.group(group);
      serverBootstrap.channel(NioServerSocketChannel.class);
      serverBootstrap.localAddress(new InetSocketAddress("localhost", 50051));

      serverBootstrap.childHandler(new ChannelInitializer<SocketChannel>() {
        protected void initChannel(SocketChannel socketChannel) throws Exception {
        }
      });

      logger.info("bind....");

      long before = System.nanoTime();
      ChannelFuture channelFuture = serverBootstrap.bind().sync();
      long after = System.nanoTime();
      logger.info("Server started, listening on " + 50051 + ". took: " + ((after - before) / 1e6));
      channelFuture.channel().closeFuture().sync();
    } catch (Exception e) {
      e.printStackTrace();
    } finally {
      group.shutdownGracefully();
    }
  }
}

I’ve simply added this to the examples of netty to try and keep anything else from affecting it.

Netty version

4.1.34.Final

JVM version (e.g. java -version)

java version "11.0.1" 2018-10-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)

OS version (e.g. uname -a)

Darwin ruben-macbook.local 18.5.0 Darwin Kernel Version 18.5.0: Mon Mar 11 20:40:32 PDT 2019; root:xnu-4903.251.3~3/RELEASE_X86_64 x86_64

[normanmaurer]

@rubensayshi I think this is related to https://thoeni.io/post/macos-sierra-java/ and so nothing to do with netty. Can you check ?

[rubensayshi]

yes, it actually is!