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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
