DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2007-03-25 07:50 ---
This seems like a nice academic and theoretical argument to me.  I too
contribute to a lot of open-source projects, and I do so with specific patch to
them: general discussions of how something might be done are nice, but useless.
 As you can see from the votes for this item and the lack of complaints about
it, ever, on any Tomcat mailing list, no one cares.

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

DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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 13:44 ---
Just to clarify, I proposed 2 ways of avoiding unexpected session expiration.

a) on the looping/sleeping thread, detect time shifts and pass it along the
stackframes to whichever class wants to know. This is when the looping code know
to few about the task to perform, for example if the looping thread doesn't know
the job is to assert/expire sessions, but it can pass its knowledge of time and
time shifts. That's the piece of code.

b) the looping/sleeping thread knows it has to age sessions. Valves or filters
(whatever on service()) simply resets the age to 0.


Note that if the duration of a sleep/wait could be affected by a system time
change, rolling back time 1 hour could lock up a thread for 1 more hour. The old
way of expiring session would be just as affected because which ever thread
checks for session expiration, it also calls wait/sleep. There is no other jvm
primitive to perform such pause. Therefore, the implementation would be just as
flawed in the worst case, and fairly expiring session in the best case.

- - -

As for wait()/sleep() JLS specs (JVM spec doesn't mention it):

http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.8.1
"If this is a timed wait, an internal action removing t from m's wait set that
occurs after at least millisecs milliseconds plus nanosecs nanoseconds elapse
since the beginning of this wait action."

http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.9
"Thread.sleep causes the currently executing thread to sleep (temporarily cease
execution) for the specified duration, subject to the precision and accuracy of
system timers and schedulers."

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

DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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:56 ---
(In reply to comment #5)
> But the following statement demonstrates your limited knowledge of what NTP
> goals are.
> 
> 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 you know so much about how all implementations of NTP operate, perhaps you
can explain to me how a datacenter I know of had all of their clocks jump
forward by five minutes, then a couple hours later jump backwards by five
minutes, and then repeat a couple more times over the next few days.  This was
under Windows, and was caused by a malfunction of their primary NTP server. 
Somehow, the primary NTP server jumping its clock caused all of the clients to
jump their clocks, despite your knowledige of how NTP operates.

The truth is that implementations of NTP can and do jump the clock, depending on
how they are implemented and how large the time difference is.  A well-mannered
implementation of NTP operates exactly as you say.  Not all implementations of
NTP are well-mannered.

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

DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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(6) 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]

DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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 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(6) 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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-09-30 16:12 ---
Let's not be narrow minded and let's not suggest tomcat is only good for http
servicing on server farms.

Tomcat can be deployed on embeded devices or appliance of all sorts that may not
have the luxury, the capacity or the access right to poll a ntp server.

Whenever a user (or the ntp update agent/service/deamon) sets the date/time,
sessions may be lost.

The only feed I can provide, which is sufficient for any willing tomcat
developer, is some design sketches.

1-Thread.sleep(n) or Object.wait(n) will always delay by the given time even if
system time changes (without interrupt() and notify[All]() interferences)

1-whenever a session is refreshed, instead of renewing (pushing in the future)
its expiration time, the code should simply reset to 0 the session 'age'.

2-whenever the session manager check (60 seconds is the default I think), it
should simply age the session (here age+=6;) and assert its validity as
expected.

It's that simple.

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

DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |enhancement




--- Additional Comments From [EMAIL PROTECTED]  2006-09-29 19:41 ---
This is an enhancement rather than a bug (so marking it as such).

I doubt there will be much (any?) interest to create a patch for this since any
well managed server would use NTP or equivalent making this enhancement 
unecessary.

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

DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2005-12-14 16:25 ---
Hello,

I try to provide solutions/proof of concepts and I rely on knowledgable coders
who can sift the good ideas from the bad ideas and ensure a patch doesn't risk
dozens of rejections because of various pickyness. I consider myself a
consultant and I'm open to questions but I cannot always write code for all
opensource projects I contribute to.

If the official team of developers cannot appreciate anything else than working
code, then the useful knowledge of the community is censored and cannot benefit
this project.

Thank you for your comprehension.


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

DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




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