tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Uploading large files and session timeout
Date Mon, 11 Jul 2011 20:54:33 GMT
Sai Pullabhotla wrote:
> A little more info on the
> org.apache.catalina.session.StandardSession.ACTIVITY_CHECK system
> property:
> 
> The last time I said that the above property is keeping the session
> alive, I was only partially correct. The way it is working is -
> 
> session is kept alive for the duration of the upload. The response is
> sent to the client indicating upload successful. However, the next
> request made immediately (I click on a button soon after the large
> upload) fails because the session is destroyed as soon as tomcat
> receives the request. What I'm rather looking for is - to keep the
> session alive for the duration of the timeout after a large upload. So
> if my session timeout is 1 minute, it would be nice if I can make a
> second request within a minute after a large upload which might have
> taken 5 minutes.
> 
> I also tried the STRICT_COMPLIANCE system property and set it to true
> to see if that makes any difference, but noticed the same behavior.
> 
> I then tried the programmatic approach as below:
> 
> Upload Servlet retrieves the current session timeout and caches it in
> a local variable (of the service/dopost).
> Changes the session timeout to 5 minutes from 30 seconds (original,
> just for testing, not that we will ever use 30 seconds in production)
> After upload finishes, and before forwarding to the JSP, the servlet
> resets the timeout to cached timeout of 30 seconds.
> 
> This did not work either, the subsequent request (right after a large
> upload which took a minute or two) fails with session timed out.
> 
> Any ideas on how to make this work?
> 

I think that you need to scroll back in this thread (to July 8), and re-read an answer 
which Charles provided to a previous question of mine.

A partial answer resides in this property, which can be adjusted in Tomcat 7 (but 
apparently not in previous releases) :

quote from : http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html

org.apache.catalina.session.StandardSession.LAST_ACCESS_AT_START	

If this is true, the last accessed time for sessions will be calculated from the beginning

of the previous request. If false, the last accessed time for sessions will be calculated

from the end of the previous request. This also affects how the idle time is calculated.

If org.apache.catalina.STRICT_SERVLET_COMPLIANCE is set to true, the default of this 
setting will be true, else the default value will be false.

unquote


To take your example above :

a) initial conditions :
- the standard session timeout is 30 seconds
- the "last access time" in the session is set at the beginning of a request (as per the 
Servlet Spec, according to Charles)

b) file upload request :
- at time T, a file upload request starts. The session timeout is 30 seconds, and the last

access time is set at T.
- your servlet sets the session timeout to 5 minutes.
- the file upload takes 3 minutes, so at the end of the file upload, the time is T+180 s.

minutes
- the servlet resets the session timeout to 30 s.
- the file upload request is finished, the servlet stops

c) a new request comes in at time T+181 s. :
- the session timeout is (again) 30 seconds
- the last access time stored in the session is T (see above)
--> the timeout is exceeded, and the session is expired

In other words, changing the session timeout during the file upload request processing 
achieved nothing.

What is needed, is either :
- while the file upload is ongoing, regularly update the session last access time, so that

it never gets "older" than the current time + the timeout.  But there seems to be no API 
for that.
OR
- arrange for the last access time to be updated /at the end/ of the file upload request,

instead of the beginning. (which seems to be possible using the system property mentioned

above, in Tomcat 7).

BUT
- I think that this is not enough, because imagine the following sequence :

timeline       Thread 1                              Threads 2..n

T :       a file upload request A starts            (nothing)
T+29 s.   file upload request A ongoing             a new request B comes in
T+60 s.   file upload request A ongoing             a new request C comes in
T+180 s.  file upload request A finishes
           session last access is updated to T+180 s.
T+200 s.  (nothing)                                 a new request D comes in

(in this, I assume that several requests can come in, in parallel, for the same session. 
Is that possible ?)

When request B comes in, the last access time in the session is still T.  That's fine, 
because it is not more than T+30 s., so the session is still valid.

When request C comes in however, the time is T+60 s., which means that the session timeout

(T+30 s.) is exceeded.  So I guess that request C will get a new session.
(And in addition, it will cancel the first session).

But for request D, it should work again, since now the last access is T+180 s., and the 
request comes in at T+200 s., which is less than 30 seconds later than T+180 s.

Now the interesting part is what happens at time T+180 s.
The original file upload request A process wants to update the session's last access time.

  But is that session still there ?


So I guess that, with Tomcat 7, the solution would be to set
org.apache.catalina.session.StandardSession.LAST_ACCESS_AT_START=false
AND
org.apache.catalina.session.StandardSession.ACTIVITY_CHECK=true

So that request C, when it comes in, finds an active session (request A), and considers 
the session valid and keeps it alive.
(And there would also be no reason then to change the session timeout back and forth).

The above may reflect my own misunderstanding of how things work though, so let's see what

the experts have to say.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message