andreacavalli/netty5
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Modify OpenSSL native library loading to accommodate GraalVM (#10395)

Browse Source 
**Motivation:**

We are interested in building Netty libraries with Ahead-of-time compilation with GraalVM. We saw there was [prior work done on this](https://github.com/netty/netty/search?q=graalvm&unscoped_q=graalvm). We want to introduce a change which will unblock GraalVM support for applications using netty and `netty-tcnative`.

This solves the error [that some others encounter](https://github.com/oracle/graal/search?q=UnsatisfiedLinkError+sslOpCipherServerPreference&type=Issues):

```
Exception in thread "main" java.lang.UnsatisfiedLinkError: io.grpc.netty.shaded.io.netty.internal.tcnative.NativeStaticallyReferencedJniMethods.sslOpCipherServerPreference()I [symbol: Java_io_grpc_netty_shaded_io_netty_internal_tcnative_NativeStaticallyReferencedJniMethods_sslOpCipherServerPreference or Java_io_grpc_netty_shaded_io_netty_internal_tcnative_NativeStaticallyReferencedJniMethods_sslOpCipherServerPreference__]
```

**Modification:**

The root cause of the issue is that in the tcnative libraries, the [`SSL.java` class](783a8b6b69/openssl-dynamic/src/main/java/io/netty/internal/tcnative/SSL.java (L67)) references a native call in the static initialization of the class - the method `sslOpCipherServerPreference()` on line 67 is used to initialize the static variable. But you see that `OpenSsl` also uses[ `SSL.class` to check if `netty-tcnative` is on the classpath before loading the native library](cbe238a95b/handler/src/main/java/io/netty/handler/ssl/OpenSsl.java (L123)). 

So this is the problem because in ahead-of-time compilation, when it references the SSL class, it will try to load those static initializers and make the native library call, but it cannot do so because the native library has not been loaded yet since the `SSL` class is being referenced to check if the library should be loaded in the first place.

**Solution:** So the proposed solution here is to just choose a different class in the `tcnative` package which does not make a native library call during static initialization. I just chose `SSLContext` if this is OK.

This should have no negative effects other than unblocking the GraalVM use-case.

**Result:**

It fixes the unsatisfied link error. It will fix error for future users; it is a common error people encounter.
This commit is contained in:
Daniel Zou 2020-07-08 04:46:38 -04:00 committed by GitHub
parent 39928e3423
commit e04803daec
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
handler/src/main/java/io/netty/handler/ssl/OpenSsl.java
View File

@ -120,7 +120,7 @@ public final class OpenSsl {
} else {
// Test if netty-tcnative is in the classpath first.
try {
Class.forName("io.netty.internal.tcnative.SSL", false, OpenSsl.class.getClassLoader());
Class.forName("io.netty.internal.tcnative.SSLContext", false, OpenSsl.class.getClassLoader());
} catch (ClassNotFoundException t) {
cause = t;
logger.debug(
@ -586,7 +586,7 @@ public final class OpenSsl {
libNames.add(staticLibName + "_" + arch);
libNames.add(staticLibName);
NativeLibraryLoader.loadFirstAvailable(SSL.class.getClassLoader(),
NativeLibraryLoader.loadFirstAvailable(SSLContext.class.getClassLoader(),
libNames.toArray(new String[0]));
}