-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Richard,
On 3/6/15 4:29 PM, Salisbury, Richard W DLA CTR INFORMATION OPERATIONS wrote: > We have found a need to stop and start Tomcat once in a while to > allow Tomcat to connect via HTTPS with some other servers. We > think the restart may be synchronizing the time Tomcat uses with > the server OS system time, and we are looking for ways to prevent > having to stop/start Tomcat. > > Details: Our instance of Tomcat 6.0.36 runs on HP-UX B11.31 ia64 > with JVM Version 1.7.0.08. It hosts a custom servlet which, when > invoked, connects with a remote server via HTTPS to retrieve some > data. However, after about a month the timestamp Tomcat sends in > the SSL handshake appears to drift enough for the remote server's > time to start rejecting requests because the timestamp is too far > off (according to our partner's remote application logs). I was about to suggest that every six months or so, you have to bounce Tomcat. But you are saying it's roughly a month. Let me tell you why I thought it might be every six months: Your JRE is quite old (if it really is 1.7.0_08), and so its got outdated time zone definitions, especially DST corrections. Oracle created a timezone-update tool because the process was getting to be a royal pain, especially with users paranoid about upgrading the JRE without 18 years of testing. http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html You can see the changelog here: http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html You'll notice that there are a whole bunch of updates to the time zones between ~2012 when 1.7.0_08 was released and now. Are you sure that Java's timestamps don't look right? Or are you just finding that SSL handshakes aren't working and blaming the "Java system time" (whatever definition that might have) for it? I like Jason Pyeron's suggestion that you create a simple JSP that will give you the current time according to Java. I think you'll find that Java's system time tracks your OS's system time exactly. We have servers running for months with no such drift, and we also use NTP (because hardware clock drift is in fact a real problem). We also run on both bare metal and virtualized hardware and have never had such problems. > We have confirmed that our server clock is set correctly and synced > with NTP, and matches the system clock on the remote server, which > also uses NTP. So one thing we thought might be happening is that > Tomcat (or the Java that Tomcat runs on) may be keeping an internal > clock, perhaps using a separate thread as a way to speed up the > retrieval of time so that it does not have to go to the OS system > clock every time it needs the current time. And maybe this > internal clock is not synced with the server time until Tomcat (or > the JVM) is restarted. Tomcat absolutely does not use any internal clock of its own. The JRE almost certainly does not, either. It should all come down the system time. Before I posted, I checked by running this Java program: import java.util.*; import java.io.*; import java.text.SimpleDateFormat; public class CurrentTime { public static void main(String[] args) throws Exception { SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); while(true) { System.out.println(df.format(new Date())); Thread.currentThread().sleep(1000); } } } This just prints the current time every second, forever. In another terminal, I performed these commands while the above program was running: $ sudo date -s '2015-03-06 17:52:00' Fri Mar 6 17:52:00 EST 2015 (wait a few seconds) $ sudo date -s '2015-03-06 17:50:00' Fri Mar 6 17:50:00 EST 2015 This is the output from the Java program: 2015-03-06 17:49:48 2015-03-06 17:49:49 2015-03-06 17:49:50 2015-03-06 17:49:51 2015-03-06 17:49:52 2015-03-06 17:49:53 2015-03-06 17:49:54 2015-03-06 17:49:55 2015-03-06 17:49:56 2015-03-06 17:52:00 2015-03-06 17:52:01 2015-03-06 17:52:02 2015-03-06 17:52:03 2015-03-06 17:52:04 2015-03-06 17:52:05 2015-03-06 17:52:06 2015-03-06 17:52:07 2015-03-06 17:52:08 2015-03-06 17:52:09 As you can see, the Java process picked-up the clock-adjustment immediately. What's interesting is that the output stalls after I reset the time back to it's correct time (17:50:00). I suspect that Thread.sleep() doesn't just set a timeout in milliseconds, but schedules a wake-up at a particular time in the future. At 17:52:09 (after the clock was pushed-up relative to the proper time), Thread.sleep() schedules a sleep until 17:52:10. At 17:52:09, I changed the time back to 17:50:00, and so it will take 2:10 for the Thread.sleep to return. I ran this again, fiddled-around with the system time and waited. Here's the output: 2015-03-06 17:52:04 2015-03-06 17:52:05 2015-03-06 17:52:06 2015-03-06 17:52:07 2015-03-06 17:52:08 2015-03-06 17:52:09 2015-03-06 17:52:10 2015-03-06 17:52:11 2015-03-06 17:52:12 2015-03-06 17:55:00 2015-03-06 17:55:01 2015-03-06 17:55:02 2015-03-06 17:55:03 2015-03-06 17:55:04 2015-03-06 17:55:05 2015-03-06 17:55:06 2015-03-06 17:55:07 2015-03-06 17:55:08 2015-03-06 17:55:09 (Here there was a 3-minute pause) 2015-03-06 17:55:10 2015-03-06 17:55:11 2015-03-06 17:55:12 2015-03-06 17:55:13 Honestly, I wasn't expecting that at all... I figured Thread.sleep(1000) meant "wake me up in 1000ms" instead of "wake me up at 17:55:10". Interesting. Anyhow, Java tracks the system time, both forward and backward, in real-time. I think your problem is elsewhere. > We did find that there is a Java Wrapper product out there by > Tanuki Software that provides an option to use system time or a > background thread, which is what caused us to wonder if Tomcat > might be doing something similar. I think this has to do with scheduling in general, and not about adjusting Java's system time (which isn't actually a thing) in any way. I think Tanuki's tool is a red herring, here. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU+jEuAAoJEBzwKT+lPKRYaOIP/0QC7fQZ88mqcy6u80GUK7EB Y55qUpB2i6Xx3X9y4uvl6TZMfB4lszreFvaGVpULjcbfgtfa0QqxRHtfTX0u5anG cCxtIcWBKQt88FK0UiJ2jHDu56dG6RLoYPkazj3lwMT6GuJ/D1L5R6PuqwVJjGxy j/OhCHhFV2sdqX5TT+TZmg7DKcMZrb6RnDwuVhZ9mkdOQ1KhsdJ+dF49l5pEpymd gLVTfNO6NkM2w1nopMfOpuVlhwRkLl8ZIfR7roCgfqq4Gk8L25SaBY6kIWheOosA d6Wj00cWZbvnSMtOI011803/drcm/DQ2hNKEfiPUVKjBTLxX4j2L1v7pH1bJRtE6 rs+x7oVyb+vYNKXSI/pblMQvGVI6+nKpjLg5aaNPyzXFUmhoy6g7/WtlNDYdICOZ 0mv+OpbgVQUG84corX9R0D5ceZkNoPW1xOwasPFsnEn3JNUwrvsk0U6kxZ9A97Uf 33bOhXdmiZGaJM+ELmeo3tnv2gohaMmf9XD/Bhm/xDcv4wjEpO0hmm4WvLH7arH4 ZCrX2LStIqT0JvLLxoURC9sptzIKG9NbXBzxeKQDn01RB4xIcx315cO+2oN4krG/ INvQbeBnEwXVbi+sYoQ8Yi+Cql3yk34h6b5PEiGcWhQYZ38FcE6jIgE7C0rmgaOh jVuH+uGuA5uH2nATUKIB =YEhT -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
