eclipse-vertx
Hanlde exception in the last handler
Motivation:
Using vert.x 3.8.5 application running HttpServer using SSL could throw exceptions like
2020-02-26T19:27:09.028Z WARN [DefaultChannelPipeline] 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.io.IOException: Connection reset by peer at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method) at java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276) at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233) at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223) at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:358) at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133) at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:834)
when connection is abruptly disconnected. The environment this was observed in is OpenShift 3.1 with the passthrough route to the server. Route health-check will try to open a connection every 5 seconds resulting in an error like this.
Adding exception handling in the last handler fixes it.
I think using SSL the Http1xUpgradeToH2CHandler should never be used because HTTP2 upgrade is only for clear text
@dejanb it is not clear according to your saying how this happens, you are mentioning the usage of SSL and the file you are patching is not used when the HTTP server handles SSL. Can you give more detail about your configuration and how this happens ? if you have a reproducer it would be great
@vietj thanks for the response. So the usage is a simple vert.x rest application running in Openshift with the route configured.
A brief analysis I did, was that handleHttp1() method (which is used during the SSL handshake) is calling configureHttp1OrH2C()
https://github.com/eclipse-vertx/vert.x/blob/4af3ca3100b5038ed0522446da6d7c812b3f3a3e/src/main/java/io/vertx/core/http/impl/HttpServerChannelInitializer.java#L163
which adds the upgrade handler by default (now I see that this can be configured with vertx.disableH2c, but it's off by default).
I think what happens is that Openshift route healt-check closes a connection mid handshake leaving us with this error log every 5 sec. It happens only after the upgrade from 3.7.x to 3.8.x.
I hope this adds a bit more context. If not I'll try to come up with a reproducer test case