azure - 如何修复 "Http11NioProtocol: Error reading request, ignored"

Question

当我的 spring-boot 应用程序在使用 SSL 的 azure kubernetes 服务上运行时，在 tomcat 服务器中使用 NPE 启动后失败。

首先，什么是成功的:我有一个使用 Spring Initializr 创建的最小 Spring-boot 应用程序:

• Gradle 项目
• Java 11
• Spring Boot 2.1.8
• 唯一的依赖项:Spring Web

我想将它与 azure 云上的 kubernetes 集群一起使用。为此，我有一个 Azure Kubernetes 服务 (AKS)。我使用 jib 来构建 docker 镜像。到目前为止，一切正常。我可以将我的 docker 镜像部署到 azure docker 注册表，启动一个 kubernetes 集群(有 1 个节点)，然后在调用“http://public-ip:8443/hello”后得到“hello world” ”。我使用端口 8443，但使用正常的 http，以确保该端口不是问题的根源。

我希望我的应用程序支持 HTTPS，因此我使用 keytool 制作了一个自签名证书(如下所述: Enable HTTPS with self-signed certificate in Spring Boot 2.0 )。这在本地主机上运行良好。它也可以在本地主机上运行的 minikube 内运行。但是当我在 AKS 上使用该 docker 镜像时，我的应用程序在启动后几秒钟就失败了。

我激活了

logging.level.org.apache.tomcat=DEBUG
logging.level.org.apache.catalina=DEBUG

在我的application.properties中。我的应用程序的输出是:

2019-09-19 08:22:51.291  INFO 1 --- [           main] com.example.demo.DemoApplication         : Started DemoApplication in 9.623 seconds (JVM running for 10.419)
2019-09-19 08:22:53.775 DEBUG 1 --- [o-8443-Acceptor] o.apache.tomcat.util.threads.LimitLatch  : Counting up[https-jsse-nio-8443-Acceptor] latch=1
2019-09-19 08:22:58.764 DEBUG 1 --- [o-8443-Acceptor] o.apache.tomcat.util.threads.LimitLatch  : Counting up[https-jsse-nio-8443-Acceptor] latch=2
2019-09-19 08:22:58.793 DEBUG 1 --- [nio-8443-exec-1] org.apache.tomcat.util.modeler.Registry  : Managed= Tomcat:type=RequestProcessor,worker="https-jsse-nio-8443",name=HttpRequest1
2019-09-19 08:22:58.793 DEBUG 1 --- [nio-8443-exec-1] org.apache.tomcat.util.modeler.Registry  : Looking for descriptor 
2019-09-19 08:22:58.793 DEBUG 1 --- [nio-8443-exec-1] org.apache.tomcat.util.modeler.Registry  : Introspecting 
2019-09-19 08:22:58.793 DEBUG 1 --- [nio-8443-exec-1] m.m.MbeansDescriptorsIntrospectionSource : Introspected attribute virtualHost public java.lang.String org.apache.coyote.RequestInfo.getVirtualHost() null
<snipped 20 lines of "Introspected attribute xyz">
2019-09-19 08:22:58.796 DEBUG 1 --- [nio-8443-exec-1] m.m.MbeansDescriptorsIntrospectionSource : Introspected attribute lastRequestProcessingTime public long org.apache.coyote.RequestInfo.getLastRequestProcessingTime() public void org.apache.coyote.RequestInfo.setLastRequestProcessingTime(long)
2019-09-19 08:22:58.796 DEBUG 1 --- [nio-8443-exec-1] m.m.MbeansDescriptorsIntrospectionSource : Introspected attribute errorCount public int org.apache.coyote.RequestInfo.getErrorCount() public void org.apache.coyote.RequestInfo.setErrorCount(int)
2019-09-19 08:22:58.796 DEBUG 1 --- [nio-8443-exec-1] m.m.MbeansDescriptorsIntrospectionSource : Setting name: org.apache.coyote.RequestInfo
2019-09-19 08:22:58.797 DEBUG 1 --- [nio-8443-exec-1] o.a.tomcat.util.modeler.BaseModelMBean   : preRegister org.apache.coyote.RequestInfo@21c6ab25 Tomcat:type=RequestProcessor,worker="https-jsse-nio-8443",name=HttpRequest1
2019-09-19 08:22:58.797 ERROR 1 --- [nio-8443-exec-1] o.a.coyote.http11.Http11NioProtocol      : Error reading request, ignored

java.lang.NullPointerException: null
    at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.getSslSupport(NioEndpoint.java:1392) ~[tomcat-embed-core-9.0.24.jar:9.0.24]
    at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:853) ~[tomcat-embed-core-9.0.24.jar:9.0.24]
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1593) ~[tomcat-embed-core-9.0.24.jar:9.0.24]
    at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) ~[tomcat-embed-core-9.0.24.jar:9.0.24]
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[na:na]
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[na:na]
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-embed-core-9.0.24.jar:9.0.24]
    at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]

谁能告诉我我的问题可能是什么？谢谢!

Answer 1

这是一个known bug在 Apache Tomcat 9.0.24 中。它是通过将纯文本发送到启用 TLS 的连接器来触发的。忽略它是安全的，但由于它相当嘈杂，您可能需要升级到最近发布的 9.0.26，该问题已得到修复。