Re: Aw: Tomcat/Java app timezone radomly changes during operation.
On 10/27/2022 6:27 PM, Peter Rader wrote: Hi David, is it a moving server? We had similar issues on a airborn server crossing nation-borders rapidly. 10 minutes is unusual. The lowest timezone-change is 15 minutes afaik. Kind regards 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 ntp is on, chrony is syncing, Java states correct time when queried however unsure if it's JDK or JRE when targeted. OS time is good. When I redeploy the app, log timestamps for the app are in UTC as well until restarting tomcat. During the issue the log timestamp remains in CDT as expected, even though values passed are UTC. I have explicitly defined the timezone in setenv.sh with no change in behavior. Any thoughts as what to investigate are greatly appreciated. Thanks, David Have you tried setting the JVM time zone with an environment variable or JVM argument or with TimeZone.setDefault? I think Mark Thomas mentioned earlier that Tomcat may invoke TimeZone.setDefault. What do mean when you say "sending UTC to the DB while it is broken"? Are you populating a date/time, time or timestamp column? Sending a date or time value for some other purpose? What is "sending UTC to the DB"? Also, what do you mean by "broken"? While what is broken? It isn't clear to me what's happening. Is the O/S time zone getting changed? Does your app run outside of Tomcat? Is your app communicating directly with the database? Is this a Java app? -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: Tomcat/Java app timezone radomly changes during operation.
Hi David, is it a moving server? We had similar issues on a airborn server crossing nation-borders rapidly. 10 minutes is unusual. The lowest timezone-change is 15 minutes afaik. Kind regards > > 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 > ntp is on, chrony is syncing, Java states correct time when queried > however unsure if it's JDK or JRE when targeted. OS time is good. > > When I redeploy the app, log timestamps for the app are in UTC as well > until restarting tomcat. During the issue the log timestamp remains in > CDT as expected, even though values passed are UTC. > > I have explicitly defined the timezone in setenv.sh with no change in > behavior. > > Any thoughts as what to investigate are greatly appreciated. > > Thanks, > David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat/Java app timezone radomly changes during operation.
David, I strongly suspect TimeZone.setDefault() is being called somewhere. I can confirm it isn't Tomcat calling it. If the problem was preceded by any application updates, I'd start looking there. Mark On 27/10/2022 16:31, David wrote: 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 ntp is on, chrony is syncing, Java states correct time when queried however unsure if it's JDK or JRE when targeted. OS time is good. When I redeploy the app, log timestamps for the app are in UTC as well until restarting tomcat. During the issue the log timestamp remains in CDT as expected, even though values passed are UTC. I have explicitly defined the timezone in setenv.sh with no change in behavior. Any thoughts as what to investigate are greatly appreciated. Thanks, David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat/Java app timezone radomly changes during operation.
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 ntp is on, chrony is syncing, Java states correct time when queried however unsure if it's JDK or JRE when targeted. OS time is good. When I redeploy the app, log timestamps for the app are in UTC as well until restarting tomcat. During the issue the log timestamp remains in CDT as expected, even though values passed are UTC. I have explicitly defined the timezone in setenv.sh with no change in behavior. Any thoughts as what to investigate are greatly appreciated. Thanks, David
Re: [OT] Compatibility, 32 bit ..
Does anyone know of a report detailing how much of this older hardware is still out there and floating around? Big picture: It's a lot of computer power in the event manufacturing hits a hiccup, I wouldn't want to be caught flat-footed until it could be re-established. I like to build distilled portable stuff for that reason. I think DB2DOM could run on some really old versions of all of our favorite software if needed. On 10/26/22, Christopher Schultz wrote: > Shawn, > > On 10/26/22 00:14, Shawn Heisey wrote: >> The Linux kernel dropped support for 386 and 486 CPUs some time ago. > > I was reading about this today, actually. Linux is currently actively > advocating for dropping 486 support, so it must still be in there. > > -chris > > - > 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
Re: Compatibility, 32 bit ..
I had the same thought when I saw it. Here is java -version output complete: openjdk version "9-internal" OpenJDK Runtime Environment (build 9-internal+0-2016-04-14-195526.buildd.src) OpenJDK Server VM (build 9-internal+0-2016-04-14-195526.buildd.src, mixed mode) On 10/26/22, Christopher Schultz wrote: > John, > > On 10/24/22 12:00, John Dale (DB2DOM) wrote: >> Hi Mark; >> Tomcat version: 10.0.27 (unzipped, chmod 770 on catalina.sh before >> cli: catalina.sh run) >> java version: openjdk version "9-internal" > > This looks fishy. Version "9-internal"? Is that a real version? > > How about you post the result of: > > $ java -version > > -chris > > - > 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
