Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
From: bugzilla@apache.org
To: tomcat-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 35746]  - session manager should be immune to
 system clock time changes (solution provided)
In-Reply-To: <bug-35746-78@http.issues.apache.org/bugzilla/>
Message-Id: <20061001074158.AB2D87142E7@brutus.apache.org>
Date: Sun,  1 Oct 2006 00:41:58 -0700 (PDT)

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 00:41 -------
While I agree with the general centiment that if an alternative algorithm works
in more cases with no loss of performance that your idea maybe sound.


But the following statement demonstrates your limited knowledge of what NTP
goals are.

(In reply to comment #4)
> Whenever a user (or the ntp update agent/service/deamon) sets the date/time,
> sessions may be lost.

An NTP client does not reset the clock when it computes a variation.  It makes
the system clock tick faster or slower to narrow that variation over time.  If
its too far out NTP will not function and abort.  Since TC is not a realtime
application and runs largely on a multitaking OS a faster/slower clock is not
ordinarly detectable by an appliction.  Which is the point of running NTP.


I'm a great believer that just as time never goes backwards that clock slew is
not something that an application programmer has to deal with.  This is one
certainty of the universe for which computer concepts live within so as such its
an underpins everything.

If you want to change the time then do so in the BIOS before the operating
system boots up, of the user changes the time force a device reboot.  If the
application of the device means you dont want this then you've going to have to
look at NTP anyway.

Some would argue that short sighted embeded device creators didn't provision an
adequate mechanism to change the clock or keep it up-to-date.  Since its a given
that the accuracy of the clock source in the device while good isn't perfect
(like most things) and the device's software relies heavily on absolute time to
function.


One question on your algorithm, is it written in the Java specification for the
Thread.sleep() function that this has to be implmented in a way impervious to
clock slew ?  Or does that claim come from your experiments with a particular
JVM implementation on the particular embeded device you have to hand ?  It is no
good building castles in the sand.


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