Tolerating significant system time adjustment

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Tolerating significant system time adjustment

Christopher Schultz-2
All,

I'm working with a partner to troubleshoot a SAML-based service where
their SAML responses are reaching us after timing-out. I tracked that
down to an incorrect system time on many of their servers.

Once fixing the clocks -- hopefully using ntpd or similar which can
smear time adjustments out over time to avoid huge, sudden clock changes
-- would they need to restart their Java VMs running Tomcat?

The only thing I can think of is that the "fast time format" used to
produce "Date" response headers and access-log timestamps might be
disturbed, but a quick look at the code doesn't lead me to believe that
it would suffer from a large system clock change. It doesn't, for
example, assume that every call to System.currentTimeMillis() /
System.nanoTime() returns a value larger (or equal to) than any previous
call.

Can anyone think of any reason why Tomcat (or the JVM) would need to be
restarted?

Thanks,
-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tolerating significant system time adjustment

Mark Thomas-2
On 16/12/2020 14:04, Christopher Schultz wrote:

> All,
>
> I'm working with a partner to troubleshoot a SAML-based service where
> their SAML responses are reaching us after timing-out. I tracked that
> down to an incorrect system time on many of their servers.
>
> Once fixing the clocks -- hopefully using ntpd or similar which can
> smear time adjustments out over time to avoid huge, sudden clock changes
> -- would they need to restart their Java VMs running Tomcat?
>
> The only thing I can think of is that the "fast time format" used to
> produce "Date" response headers and access-log timestamps might be
> disturbed, but a quick look at the code doesn't lead me to believe that
> it would suffer from a large system clock change. It doesn't, for
> example, assume that every call to System.currentTimeMillis() /
> System.nanoTime() returns a value larger (or equal to) than any previous
> call.
>
> Can anyone think of any reason why Tomcat (or the JVM) would need to be
> restarted?

Restarted? No.

You might see things like:
- longer/shorter (possibly negative) request processing times
- earlier than expected session timeouts
- etc.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tolerating significant system time adjustment

Christopher Schultz-2
Mark,

On 12/16/20 11:04, Mark Thomas wrote:

> On 16/12/2020 14:04, Christopher Schultz wrote:
>> All,
>>
>> I'm working with a partner to troubleshoot a SAML-based service where
>> their SAML responses are reaching us after timing-out. I tracked that
>> down to an incorrect system time on many of their servers.
>>
>> Once fixing the clocks -- hopefully using ntpd or similar which can
>> smear time adjustments out over time to avoid huge, sudden clock changes
>> -- would they need to restart their Java VMs running Tomcat?
>>
>> The only thing I can think of is that the "fast time format" used to
>> produce "Date" response headers and access-log timestamps might be
>> disturbed, but a quick look at the code doesn't lead me to believe that
>> it would suffer from a large system clock change. It doesn't, for
>> example, assume that every call to System.currentTimeMillis() /
>> System.nanoTime() returns a value larger (or equal to) than any previous
>> call.
>>
>> Can anyone think of any reason why Tomcat (or the JVM) would need to be
>> restarted?
>
> Restarted? No.
>
> You might see things like:
> - longer/shorter (possibly negative) request processing times
> - earlier than expected session timeouts
> - etc.

Thanks for the confirmation. Any temporary weirdness (e.g. negative
processing times) would be (somewhat) expected and ignored.

Their application... well, know knows what assumptions that makes :)

Thanks,
-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]