чт, 27 окт. 2022 г. в 18:31, David <rax1...@gmail.com>: > > Hi all, > > I've experienced an issue since the morning of the 21st that I'm > hoping to get some direction on for where to look. > > An app uses the date/time to set a timeout for a password reset. > This had been working fine for years and suddenly it failed. A restart of > tomcat allowed it to work for a day, then 12 hours, then 5 hours, then 1 hr > and now is averaging a 10 minute or so working duration between tomcat > restarts. > > Changing the logging in the app showed that the issue is due to it > sending UTC to the DB while it is broken. Restarting Tomcat results in CDT > being sent for a while until randomly it switches again. > > RHEL 7.9, jvm 1.8.0_231-b11, Tomcat 9.0.29
Looking at the changelog since 9.0.29 onwards, there was the following issue, fixed in 9.0.34 two years ago: https://bz.apache.org/bugzilla/show_bug.cgi?id=64226 "Tomcat 9 can return HTTP date headers in timezone other than GMT" Fixed by commit https://github.com/apache/tomcat/commit/f64a2a7150bff01bca479c7c319b7e8db879df26 It is about how parsing a date time string may affect formatting time if the same SimpleDateFormat instance is reused. It is triggered by a client sending a header using a different time zone. It is unlikely your issue with the database (unless your application uses Tomcat internal classes such as ConcurrentDateFormat or FastHttpDateFormat), but it affects HTTP headers generated by Tomcat. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
