tomcat - CloseNowException : This stream is not writeable

Question

我真的很难过。在我的服务器日志中，我看到:

org.apache.coyote.CloseNowException: Connection [215], Stream [95], This stream is not writable
        at org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize(Http2UpgradeHandler.java:843) ~[tomcat-coyote.jar:9.0.30]
        at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:940) ~[tomcat-coyote.jar:9.0.30]
        at org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:859) ~[tomcat-coyote.jar:9.0.30]
        at org.apache.coyote.http2.Http2OutputBuffer.doWrite(Http2OutputBuffer.java:59) ~[tomcat-coyote.jar:9.0.30]
        at org.apache.coyote.Response.doWrite(Response.java:601) ~[tomcat-coyote.jar:9.0.30]

当用户点击太快时似乎会发生这种情况，但这没有意义，因为 Tomcat 应该能够处理大量请求。这是在负载非常轻的服务器上，在非常快的机器上，每秒可能有 2 或 3 个 HTTP 请求。

这是使用 Spring Boot 2 和 Tomcat 9.0.30。真是令人费解。

我确实在 SO 上看到了一个类似的问题，有人使用网络推送得到了这个问题，但我们没有。

以下是我们的 HTTP/2 连接器的配置方式:

<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="150" SSLEnabled="true"
           keystoreFile="/etc/ssl/keys.p12"
           keystorePass="changeit"
           keyAlias="tomcat"
           sslProtocol="TLS"
           sslEnabledProtocols="TLSv1.3,TLSv1.2"
           connectionTimeout="20000"
           >
  <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"
                   keepAliveTimeout="20000"
                   />
</Connector>

它在 Ubuntu 服务器 18.04 上的 JDK 13.0.2 上运行。

对此有何想法？这绝对是用户注意到的事情，我不知道如何解决这个问题。

Answer 1

这个问题实际上并没有消失。我尝试了很多很多东西。我在 9.0 系列的几个较新版本的 Tomcat 上尝试了这个。我升级到 JDK 14、14.0.1 和 14.0.2，全部来自 Oracle(我从未尝试过 OpenJDK 版本，无法想象它会有什么不同)。我尝试了各种 TLS 设置，包括将其限制为仅 TLS1.3。
问题还在继续。
我尝试运行一个完全不同的 Spring Boot 应用程序，该应用程序必须向服务器发送大量小型(500 字节)JSON POST。通常这些 POST 消息会失败。它在某些浏览器上经常发生，但在其他浏览器上没有。这没有任何明确的模式。这些将是在 Windows、Linux 和 Safari 以及移动设备上运行的浏览器。有时它起作用有时不起作用。
通常最有可能失败的 GET 是获取小的静态对象，比如一个小的 CSS 文件，这实际上应该是最容易和最快加载的东西。作为一个副作用，未能加载 CSS 完全破坏了网站，所以这真的很糟糕。
所以我们有许多不同版本的 Tomcat，许多 JDK 版本，许多不同的 http2 和 TLS 配置参数变体，以及两个完全不同的 Spring Boot 应用程序，我们遇到了同样的问题:http2 session 的偶发失败。这里唯一的共同点是，当我切换回 http1.1 时，所有问题都消失了。
与 http2 相比，Http1.1 的性能要差得多，但我希望它能够正常工作。
无奈之下我想，好吧，唯一没有改变的是服务器软件，我知道Jetty的http2实现与Tomcat的完全不同。
我切换到基本的 Jetty 配置，启用了 http2，部署了我的应用程序并对其进行了测试。所有的 http2 问题都消失了。它开始按预期运行，性能良好，并具有 http2 的性能优势。此开关修复了之前出现问题的两个 Spring Boot 应用程序上的问题。顺便说一下，这两个 Spring Boot 应用程序非常不同，一个涉及数据库和 Spring Integration 以及大量功能，另一个简单得多，涉及读取和写入一些小文件。
我在这里只能得出一个结论:Tomcat 的 http2 实现有问题，它没有经过足够的测试或实际使用，不应该在生产中使用。这是一件痛苦的事情，因为我多年来一直使用 Tomcat 作为我的首选服务器，我认为 Tomcat 版本会稳定并且可以生产，但事实并非如此。如果您遇到这些“关闭的流”错误，客户端只是无法加载，并且它是立即发生的，而不是在任何超时之后，并且它发生在 http2 而不是 http1，然后尝试切换到 Jetty，看看是否有所不同。如果有任何 Tomcat 开发人员想要进一步研究，请回复此内容，我可以将我们的系统设置为演示。
考虑到 Tomcat 是最古老和使用最广泛的 Servlet 容器，我确实非常偏向于支持 Tomcat，但此时我得出的结论是 Jetty 将成为我的首选。
我希望这篇文章可以帮助其他可能遇到这个问题的人，因为这确实不容易弄清楚，最后我一直没有弄清楚发生了什么，除了 Tomcat 的 http2.