headers
bugzilla | 1 Oct 2006 01:12
Picon
Favicon

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

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 <at> yahoo.com  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+=60000;) and assert its validity as
expected.
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 1 Oct 2006 09:41
Picon
Favicon

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

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 <at> 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 1 Oct 2006 12:12
Picon
Favicon

DO NOT REPLY [Bug 34956] - Tomcat should enforce the requirements from servlet 2.4 specification SRV.8.2

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=34956>.
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=34956

------- Additional Comments From remm <at> apache.org  2006-10-01 03:12 -------
If you add support for this "feature", don't forget to use
Globals.STRICT_SERVLET_COMPLIANCE, because besides annoying some people, this
won't have any real value.

--

-- 
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.
Permalink | Reply | 0 comments |
headers
rjung | 1 Oct 2006 14:19
Picon
Favicon

svn commit: r451742 - in /tomcat/site/trunk: docs/download-connectors.html xdocs/download-connectors.xml

Author: rjung
Date: Sun Oct  1 05:19:01 2006
New Revision: 451742

URL: http://svn.apache.org/viewvc?view=rev&rev=451742
Log:
Update download version for mod_jk from 1.2.18 to 1.2.19.
I did this already on the web site as part of the release process,
but forgot to update the svn sources for the web site :(

Modified:
    tomcat/site/trunk/docs/download-connectors.html
    tomcat/site/trunk/xdocs/download-connectors.xml

Modified: tomcat/site/trunk/docs/download-connectors.html
URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/download-connectors.html?view=diff&rev=451742&r1=451741&r2=451742
==============================================================================
--- tomcat/site/trunk/docs/download-connectors.html (original)
+++ tomcat/site/trunk/docs/download-connectors.html Sun Oct  1 05:19:01 2006
 <at>  <at>  -218,18 +218,18  <at>  <at> 
 </div>
         <ul>
 <li class="download">
-<a
href="[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.18/tomcat-connectors-1.2.18-src.tar.gz">JK
1.2.18 Source Release tar.gz</a>
+<a
href="[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.19/tomcat-connectors-1.2.19-src.tar.gz">JK
1.2.19 Source Release tar.gz</a>
         <ul class="attributes">
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 1 Oct 2006 14:42
Picon
Favicon

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

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 <at> 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...
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 1 Oct 2006 16:42
Picon
Favicon

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

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 <at> 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:
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 1 Oct 2006 16:56
Picon
Favicon

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

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 edward.kuns <at> concerto.com  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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 1 Oct 2006 22:44
Picon
Favicon

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

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 <at> yahoo.com  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):
(Continue reading)

Permalink | Reply | 0 comments |
headers
markt | 2 Oct 2006 00:43
Picon
Favicon
Gravatar

svn commit: r451831 - in /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core: ApplicationDispatcher.java ApplicationFilterChain.java LocalStrings.properties

Author: markt
Date: Sun Oct  1 15:43:11 2006
New Revision: 451831

URL: http://svn.apache.org/viewvc?view=rev&rev=451831
Log:
Fix bug 34956. Ensure requestDispatchers are called with original or wrapped original request/response
objects as per SRV.8.2 and SRV.14.2.5.1

Modified:
    tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
    tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java
    tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/LocalStrings.properties

Modified: tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
URL: http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java?view=diff&rev=451831&r1=451830&r2=451831
==============================================================================
---
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java (original)
+++
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
Sun Oct  1 15:43:11 2006
 <at>  <at>  -323,6 +323,9  <at>  <at> 

         // Set up to handle the specified request and response
         setup(request, response, false);
+        
+        // Check SRV.8.2 / SRV.14.2.5.1 compliance
+        checkSameObjects();
(Continue reading)

Permalink | Reply | 5 comments |
headers
bugzilla | 2 Oct 2006 00:45
Picon
Favicon

DO NOT REPLY [Bug 34956] - Tomcat should enforce the requirements from servlet 2.4 specification SRV.8.2

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=34956>.
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=34956

markt <at> apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

------- Additional Comments From markt <at> apache.org  2006-10-01 15:45 -------
This has been fixed in SVN for 5.5.x and will be included in 5.5.21 onwards.
When ported to 6.0.x this code will be wrapped in a check for
Globals.STRICT_SERVLET_COMPLIANCE==true

--

-- 
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.
Permalink | Reply | 0 comments |

Gmane