Upgrading netty-tcnative to 2.0.36.Final for ARM

[suztomo]

Netty-tcnative was not working for ARM machine (aarch64) before 2.0.36.Final, because of the filename mismatch when loading "libnetty_tcnative_linux_aarch_64.so".

Here is my project to reproduce the problem on ARM machines: https://github.com/suztomo/netty-shaded-openssl

The problem has been fixed in 2.0.36.Final (latest) netty/netty-tcnative#552 (comment). With this version, my project above passes the test.

Reference: previous commit that touched netty-tcnative version: 8359d0b#diff-49a96e7eea8a94af862798a45174e6ac43eb4f8b4bd40759b5da63ba31ec3ef7R177

[suztomo]

IntelliJ told me this is unused.

[ejona86]

This is going to take a bit more time than normal because netty-tcnative changed their build system in a weird way (netty-jni-util), which causes problems for internal building/testing.

[suztomo]

Windows failure (I don't know what to fix):

T:\src\github\grpc-java\grpc-java-helper64>powershell -command "$ErrorActionPreference = 'stop'; & { [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 ; iwr https://github.com/google/protobuf/archive/v3.12.0.zip -OutFile protobuf.zip }"   || exit /b 1

iwr : Unable to connect to the remote server

At line:1 char:120

+ ... Type]::Tls12 ; iwr

@ejona86 Thank you for responding and checking the internal testing problem!

[ejona86]

There are more issues. We won't be able to upgrade to 2.0.36. Filed netty/netty-jni-util#5. It should only be small changes, but needs new releases of all components.

[ejona86]

@suztomo, do you have a workaround and were just wanting this for performance? If you just want things to work using Java 11+ is an option. For performance conscrypt-openjdk-uber and grpc-netty are options.

[suztomo]

I was just poking around Google Java libraries on ARM (and found this netty problem in googleapis/java-bigtable-hbase#2900) Nobody is complaining so far.

I'll try to run the same test on Java 11.

[suztomo]

The test (GrpcNettyShadedOpenSSLTest) fails in Java 11. https://gist.github.com/suztomo/46d00484849aa6a06c09ad49d60b86f2

I think I didn't interpret your comment correctly. (For example, do you mean java-bigtable-hbase does not need to rely on netty-tcnative (io.netty.handler.ssl.OpenSsl) if users are on Java 11?)

[ejona86]

Everything should work without netty-tcnative with recent versions of Java 8 or later, but there may be a performance impact. Since Java 11, the performance difference between netty-tcnative and Java's built-in TLS is not that large. Since Java 11 and recent versions of Java 8 which received the ALPN backport, ALPN is no longer an issue.

[ejona86]

Ah! This is why #7830 sounded familiar. Anyway, there's plans to upgrade Netty this quarter, and we we'll have to upgrade past 2.0.36 anyway due to the jni-util issues that have since been fixed. I'm going to close this and let #7830 track the ARM incompatibility.

[suztomo]

Thank you for update 👍