When netty_transport_native_epoll_x86_64 cannot be found, stacktrace is logged

Expected behavior

When the library “netty_transport_native_epoll_x86_64” cannot be loaded, log the error at DEBUG but don’t log a “scary” stack trace that users may construe as an error, when, in fact, the library is loaded fine through another mechansism, which is logged later: 1582 [main] DEBUG io.netty.util.internal.NativeLibraryLoader - Successfully loaded the library /tmp/libnetty_transport_native_epoll_x86_646303477118324058101.so

Actual behavior

“scary” stacktrace is logged if users are running with debug logging, and they wonder if there is an error.

05:30:46.950 [main] DEBUG io.netty.util.internal.NativeLibraryLoader - -Dio.netty.native.workdir: /tmp (io.netty.tmpdir)
05:30:47.013 [main] DEBUG io.netty.util.internal.NativeLibraryLoader - Unable to load the library 'netty_transport_native_epoll_x86_64', trying other loading mechanism.
java.lang.UnsatisfiedLinkError: no netty_transport_native_epoll_x86_64 in java.library.path
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
	at java.lang.System.loadLibrary(System.java:1122)
	at io.netty.util.internal.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:38)
	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.util.internal.NativeLibraryLoader$1.run(NativeLibraryLoader.java:229)
	at java.security.AccessController.doPrivileged(Native Method)
	at io.netty.util.internal.NativeLibraryLoader.loadLibraryByHelper(NativeLibraryLoader.java:221)
	at io.netty.util.internal.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:207)
	at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:118)
	at io.netty.channel.epoll.Native.loadNativeLibrary(Native.java:199)
	at io.netty.channel.epoll.Native.<clinit>(Native.java:61)
	at io.netty.channel.epoll.Epoll.<clinit>(Epoll.java:33)
	at com.twitter.finagle.netty4.nativeEpoll$.enabled$lzycompute(nativeEpoll.scala:14)
	at com.twitter.finagle.netty4.nativeEpoll$.enabled(nativeEpoll.scala:14)
	at 

Steps to reproduce

Minimal yet complete reproducer code (or URL to code)

Netty version

4.1.16.Final

JVM version (e.g. java -version)

OS version (e.g. uname -a)

[pcj]

I agree with @jcrossley on this one. It’s plenty information to just log the attempted load path in debug mode. Stacktrace is not expected behavior for a java app, even at debug level. Wastes people’s time (like mine!) to hunt down this issue.

[enesunal]

Setting log level to debug for my project doesn’t mean I set it to debug for libraries. Please exclude the stack traces when you’re releasing for production. It’s the default log level(debug) for almost any developer who tries to make things work, these stacktraces just make initial development harder. If it’s important, you can even print a warning explaining the issue.