I was able to narrow down the issue and find a workaround. If anyone has else seen this issue, I would be interested in hearing about it.
Here is a recap of the issue. The Spring Boot app works fine at openjdk 1.8. When the app is moved to openjdk 17, the app works initially and then usually within a few minutes the web browser starts clocking and then times out. The underlying issue has to do with TLS session tokens. There appears to be a defect in the web browser (Windows 10 in this case) TLS code where it starts throwing the following error after the first TLS connection closes and it tries to start another TLS connection. [13132:2960:0904/130325.068:ERROR:ssl_client_socket_impl.cc(882)] handshake failed; returned -1, SSL error code 1, net_error -101 The web browser then never does actually get a ClientHello over to the Apache Tomcat server, as it is stuck in hitting those ssl_client_socket errors in the attempt to start the TLS handshake. Adding this JVM argument to the Spring Boot app fixes the issue and the app can run fine at openjdk 17. jdk.tls.server.enableSessionTicketExtension=false This turns off the TLS session tickets functionality and the issue goes away. I don't really need the performance improvement of TLS session tickets, so this is a viable workaround for the issue. -----Original Message----- From: Tim Zielke Sent: Thursday, August 15, 2024 9:55 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: RE: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux When the web browser clocking issue happens, the web browser will just clock when I click on a link in this application and then eventually time out on the browser side. The TCP connections mentioned in original posting represent this web browser click that clocked and eventually timed out at the browser. The Spring Boot trace is showing that the https request are making it to the server side socket and nio-exec threads are starting to act on it. There are several nio-exec threads doing a read register on the socket (within the same millisecond), but then nothing else happens with the socket. There is no nio-exec write register or reading/processing https data from the socket. After 60 seconds, the connections are closed due to the server.tomcat.keep-alive-timeout default setting. -----Original Message----- From: Mark Thomas <ma...@apache.org> Sent: Thursday, August 15, 2024 9:35 AM To: users@tomcat.apache.org Subject: Re: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux [You don't often get email from ma...@apache.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] [External] On 15/08/2024 14:36, Tim Zielke wrote: <snip/> > web browser clocking issues <snip/> Can you clarify what you mean by this please. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
