Grpc-java: Stop telling people Jetty ALPN has not been configured

[ejona86]

If both OpenSsl (tcnative) and Jetty ALPN are unavailable then we end up failing with "Jetty ALPN/NPN has not been properly configured". We should tell them to configure tcnative, and not encourage the use of Jetty ALPN.

[conorgriffin]

I have configured tcnative (as far as I can tell) but I get this error.

Exception in thread "main" java.lang.IllegalArgumentException: Jetty ALPN/NPN has not been properly configured.
    at io.grpc.netty.GrpcSslContexts.selectApplicationProtocolConfig(GrpcSslContexts.java:174)
    at io.grpc.netty.GrpcSslContexts.configure(GrpcSslContexts.java:151)
    at io.grpc.netty.GrpcSslContexts.configure(GrpcSslContexts.java:139)
    at io.grpc.netty.GrpcSslContexts.forServer(GrpcSslContexts.java:130)

If I set the log level to debug I actually get something more helpful which is the following message prior to the exception above:

java.lang.UnsatisfiedLinkError: no provided in java.library.path
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867) ~[na:1.8.0_121]
    at java.lang.Runtime.loadLibrary0(Runtime.java:870) ~[na:1.8.0_121]
    at java.lang.System.loadLibrary(System.java:1122) ~[na:1.8.0_121]
    at org.apache.tomcat.jni.Library.<init>(Library.java:80) ~[tomcat-embed-core-8.5.6.jar:8.5.6]
    at org.apache.tomcat.jni.Library.initialize(Library.java:180) ~[tomcat-embed-core-8.5.6.jar:8.5.6]
    at io.netty.handler.ssl.OpenSsl.initializeTcNative(OpenSsl.java:417) ~[netty-handler-4.1.8.Final.jar:4.1.8.Final]
    at io.netty.handler.ssl.OpenSsl.<clinit>(OpenSsl.java:101) ~[netty-handler-4.1.8.Final.jar:4.1.8.Final]
    at io.grpc.netty.GrpcSslContexts.defaultSslProvider(GrpcSslContexts.java:158) [grpc-netty-1.3.0.jar:1.3.0]
    at io.grpc.netty.GrpcSslContexts.configure(GrpcSslContexts.java:139) [grpc-netty-1.3.0.jar:1.3.0]
    at io.grpc.netty.GrpcSslContexts.forServer(GrpcSslContexts.java:130) [grpc-netty-1.3.0.jar:1.3.0]

However, this isn't much help in itself since from what I can tell tcnative should work since I have the dependency in my pom file as follows:

        <dependency>
            <groupId>io.netty</groupId>
            <artifactId>netty-tcnative-boringssl-static</artifactId>
            <version>1.1.33.Fork26</version>
        </dependency>

Have I missed something or am I getting this in error. I feel that the UnsatisfiedLinkError should be a warning instead of a debug message at least.

[jorgheymans]

@conorgriffin are you running under tomcat ? https://github.com/netty/netty-tcnative/issues/214

[conorgriffin]

yeah so that was the issue but was only able to see a message helping me to find the root cause by using debug logging, I'd have expected a warning at least. I am running spring boot so I had to switch to using jetty instead of the built-in tomcat

Thanks for the tip on the other issue all the same

[ejona86]

@conorgriffin, grpc-java 1.4.0 release should fix the Tomcat incompatibility.

[conorgriffin]

when is the 1.4.0 release scheduled?

[carl-mastrangelo]

@conorgriffin It was released about a week ago: https://github.com/grpc/grpc-java/releases/tag/v1.4.0

[conorgriffin]

Ah! I had just checked the README on master which still says 1.3.0.

Thanks

[ejona86]

It looks like I'll naturally be fixing this as I add Conscrypt support in the Netty transport.

[saturnism]

Not sure when conscrypt will be in, but if it's going to take a while, it can be helpful to change the error message and refer the user to read https://github.com/grpc/grpc-java/blob/master/SECURITY.md :)

[saturnism]

also, suggest adding common troubleshooting techniques and resolutions, especially when trying to determining if it's a classpath conflict.

[lesv]

This happens a lot - we are getting this from various sources. It would be nice if the error was changed to both talk about alternative choices, it should also talk about using mvn dependency:tree and using <dependencyManagement> to fix the version of Netty being used.

Also it would be nice if you could check that it's a dependency issue at runtime and differentiate between the possible causes and give a better error message.

[ejona86]

This was fixed by #3604

[j256]

For the record, ALPN errors can be generated because of mismatched 32 versus 64 bit, wrong JRE versions specified in build or test scripts, etc..

[j256]

Also, older servers with glibc < version 2.7 will not work because of netty requirements. Yes, sigh, in 2018 my company has to support our code on these older servers.