tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: How to force Tomcat to use the system clock?
Date Fri, 06 Mar 2015 22:58:54 GMT
Hash: SHA256


On 3/6/15 4:29 PM, Salisbury, Richard W DLA CTR INFORMATION OPERATIONS
> 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  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.

You can see the changelog here:

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

Before I posted, I checked by running this Java program:
import java.util.*;
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()));

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

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

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
Version: GnuPG v1
Comment: GPGTools -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message