Closed vcariven closed 5 years ago
Hi @vcariven
Please downgrade the ALPN agent from 2.0.9 to 2.0.8 api_gateway_home/boot https://search.maven.org/remotecontent?filepath=org/mortbay/jetty/alpn/jetty-alpn-agent/2.0.8/jetty-alpn-agent-2.0.8.jar
Don't forget to update the bin/gravitee script to take care of this change.
Regards,
I've miss to inform you that we are not supporting JDK 11 yet.
Regards,
Hello,
Thanks for your quick answer and the information about the JDK 11 support. As it is not yet supported, JDK is though not an option. Have you got some explaination regarding the error reported and the behaviour difference between the two openjdk 8 minor versions (181 and 191) ?
Hi @vcariven
Did you have a look to my previous comment ? https://github.com/gravitee-io/issues/issues/1854#issuecomment-457605014
Sorry, I thought your comment was related to jdk11 (as startup logs in jdk11 mentioned alpn). I'll give the alpn downgrade a try today on jdk 8 and will keep you informed.
Thanks.
Hi @brasseld
I have just tested with jetty-alpn-agent-2.0.8.jar (and the related changes in the boot script) and the same error is raised :
[2019-01-28 09:41:54,913][WARN][io.netty.channel.DefaultChannelPipeline][vert.x-eventloop-thread-4] An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
java.lang.NoSuchMethodError: sun.security.ssl.SSLSessionImpl.<init>(Lsun/security/ssl/ProtocolVersion;Lsun/security/ssl/CipherSuite;Ljava/util/Collection;Lsun/security/ssl/SessionId;Ljava/lang/String;IZ)V
at sun.security.ssl.ClientHandshaker.serverHello(ClientHandshaker.java:723)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:210)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:992)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:989)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467)
at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1408)
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1316)
at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1159)
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1194)
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:438)
at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:255)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1359)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:935)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:141)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
So you've tested 2.0.8 with which version of JDK ?
openjdk version "1.8.0_181" OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13) OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
hi @vcariven ,
I've tested gravitee 1.21.2 (with the default alpn.jar v2.0.9), with jdk 1.8.0_181 with success :
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_181-b13)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.181-b13, mixed mode)
The bootstrap of the gateway :
=========================================================================
Gravitee.IO Standalone Runtime Bootstrap Environment
GRAVITEE_HOME: /Users/nicolasgeraud/Work/graviteeio-versions/graviteeio-full-1.21.2/graviteeio-gateway-1.21.2
GRAVITEE_OPTS:
JAVA: /Users/nicolasgeraud/.jenv/versions/1.8.0.181/bin/java
JAVA_OPTS: -Xms512m -Xmx512m -Djava.awt.headless=true -XX:+HeapDumpOnOutOfMemoryError -XX:+DisableExplicitGC -Dfile.encoding=UTF-8
CLASSPATH: /Users/nicolasgeraud/Work/graviteeio-versions/graviteeio-full-1.21.2/graviteeio-gateway-1.21.2/lib/gravitee-gateway-standalone-bootstrap-1.21.2.jar
=========================================================================
Can you share a complete gravitee.log file ?
Hi @vcariven
What is the status of this ticket ?
Thanks for your feedback.
Regards,
Hello,
This seems to be related to an incompatibility between debian 9 (stretch) openjdk 8 package and netty library. I think @NicolasGeraud has reproduced the issue.
Regards
No he doesn't:
I've tested gravitee 1.21.2 (with the default alpn.jar v2.0.9), with jdk 1.8.0_181 with success :
I thought he had. Issue can be reproduced by building a gravitee docker image inheriting from docker.io/openjdk:8-jre-stretch
This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.
When configuring an https proxy endpoint target, the gateway fails with a
java.lang.NoSuchMethodError
exception when running with openjdk 8u181 from debian stable channel (stretch).The error does not happen when installing openjdk 8u191 from unstable channel (sid).
It seems that
sun.security.ssl.SSLSessionImpl.<init>()
contructor implementation has changed between versions 8u181 and 8u191 which could be the error cause. I have noticed that no gravitee package is involved in this stacktrace but only netty ones. This surely means that this is related with embedded netty libraries.Similar incompatibility issues regarding this class implementation have been reported on internet (either from 8u181 to 8u191 or the other way : 8u191 to 8u181) :
Expected Behavior
The proxified https endpoint should be made available through gravitee gateway without error with one or the other jvm (8u181 or 8u191).
Current Behavior
The gateway reports the following error :
Possible Solution
Steps to Reproduce (for bugs)
NoSuchMethodError
Context
Your Environment