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 14:42:50 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 darryl@darrylmiles.org  2006-10-01 07:42 -------
(In reply to comment #6)
> 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.

To reconfirm my opening comment, if your proposal makes thing work in more cases
without any side-effects or performance impact I can't see any objection for it.
 Maybe you could confirm this is the case once you work out a patch.

But to be clear you're not able to cite any contractual Java API requirement
that Thread.sleep() must always work the way you describe on all JVMs on all
operating systems.  You can only say it works in the case you tested.

The bigger question here is that you are fixing only one issue where comparisons
to absolute system time are being made, how many other parts of the code are
affected to.  Should a complex application (like TC) be expected to deal with
time going backwards (it is a given that applications can already deal
gracefully with time going forwards).


Thinking down the road towards a solution:

Let suppose you were able to detect a slew occur, and calculate how much slew
occured.
The session expiry may not be the only place affected, you might also need to
modify the code which accesses a session (if that code is doing an expiry check
on every access).  Everytime a session is accessed a clock slew detection
algorithm would need to detect slew.  if(currentTime < session.lastAccessedTime
|| currentTime > (session.lastAccessedTime + expiryIntervalTime +
miniLatencyMargin)) { sessionFixSlew(); }  Maybe that works providing the
expiryIntervalTime is less than half the session timeout.  Maybe that works
providing you dont care about slew of less than expiryIntervalTime not being
detectable.
Maybe the solution calls for a custom StandardSession implementation.


As for your other comments..

I disagree with your x0.5 through x2 values, sure its theoretically possible to
do but who is doing it ?  Maybe x0.98 to x1.02 is more realistic value to cite.

I disagree with your datacentre argument, on some unix the "clock" tool allow
setting of BIOS clock without needing to go into the BIOS.  It pretty obvious to
me how the construct a mechanism in an embeded device to change the clock you
either do it last thing just before issuing a hardware reset (as part of the
procedure to change the clock) or you store a +/- modification value in some
non-volatile place and just as the OS boots up it make the correction.  A bit
like the old /etc/ntp.drift file.

Implementing RTC updating, kernel adjtimex support and a basic NTP client are
substantially less work than implementing a JVM and if an embeded device has
resources to run a JVM (and tomcat inside that) then we're not talking about no
microPU for a washing machine are we.


-- 
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