tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)
Date Sun, 01 Oct 2006 12:42:22 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35746>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35746





------- Additional Comments From quartz12h@yahoo.com  2006-10-01 05:42 -------
The point is not about NTP. The point is that on systems where time can be set
by the user, sessions could be lost. Going into the bios is not an option for
servers in a remote datacenter. Embeded systems and appliance do not expose the
boot swequence nor the bios. Assume the system we are talking about here is
offering the user the option to set time.

I just wanted to share my experience and provide a resilient session expiration
mecanism.

- - -

Notes on ntp:

NTP agents can either accellerate, decellerate or set the clock, depending on
how you configure it. If you try to rewind time by an hour, it would take
minimum 1 hour assuming the clock can literally stop. In most case this is not
acceptable. If you wanted to advance clock by 1 hour while time could accelerate
to 2x, you would still need 1 hour to do so, and the device would be taxed by
having to do all its scheduled jobs twice as much with the same hardware. From
an other angle, the hardware is effectively 2x slower. For example, thinks about
backups, scheduled purges, mailouts, etc...

I know very well the effect of time "warping", we wrote a kernel module to
simulate weeks of uptime in a few hours (ex: for 100x speed, simply add 100
jiffies instead of 1). Note that this does shorten the actual duration of
sleep() and wait(), which is why it worked for our long uptime simulations (the
entire linux kernel relies on that time we tweak).

However, I don't know if NTP updates are playing with jiffies or if the
sleep()/wait() would be unaffected.

What I do know, is that you can write a simple java program that just
sleep(60000) and while it sleeps, you can set (not drift) the time all you want,
there is no forcing sleep() to last shorter nor longer.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message