netty: 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)
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 13
- Comments: 28 (8 by maintainers)
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.
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.
@johnou I would expect it to log, yes, but would be great if it didn’t have those stacktraces, too. Our customers are routinely alarmed by them.
@jcrossley IMHO you should expect to have a noisy log if you use debug logging. Why not just change the log level if you think its too verbose ?
this stack traces information on debug level actually confuse me
Actually we log the stack trace to make it easier to debug stuff. Do you think its too noisy ?
The stacktrace is essential for debugging native library loading problems (especially when Netty is shaded).
Hi , finally what is the solution ? I am using <dependency> <groupId>io.netty</groupId> <artifactId>netty-all</artifactId> <version>4.1.31.Final</version> </dependency>
<dependency> <groupId>io.netty</groupId> <artifactId>netty-transport-native-epoll</artifactId> <version>4.1.31.Final</version> <classifier>linux-x86_64</classifier> </dependency>but still getting same error …what is the solution for this error :?
Suppressed: 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 io.netty.util.internal.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:243) at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:124) … 43 more Suppressed: java.lang.UnsatisfiedLinkError: no netty_transport_native_epoll_x86_64 in java.library.path
but still getting same error …what is the solution for this error :?
@normanmaurer our customers sometimes set it to debug. But I understand what you’re saying, fair point. I’ll close this. Thanks!.