Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 81D1E4A5A for ; Mon, 11 Jul 2011 20:55:16 +0000 (UTC) Received: (qmail 6743 invoked by uid 500); 11 Jul 2011 20:55:13 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 6557 invoked by uid 500); 11 Jul 2011 20:55:12 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 6548 invoked by uid 99); 11 Jul 2011 20:55:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Jul 2011 20:55:12 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates 212.85.38.228 as permitted sender) Received: from [212.85.38.228] (HELO tor.combios.es) (212.85.38.228) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Jul 2011 20:55:03 +0000 Received: from [192.168.245.129] (p549E0643.dip0.t-ipconnect.de [84.158.6.67]) by tor.combios.es (Postfix) with ESMTPA id 099842008E for ; Mon, 11 Jul 2011 22:54:40 +0200 (CEST) Message-ID: <4E1B6309.6050603@ice-sa.com> Date: Mon, 11 Jul 2011 22:54:33 +0200 From: =?ISO-8859-1?Q?Andr=E9_Warnier?= Reply-To: Tomcat Users List User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tomcat Users List Subject: Re: Uploading large files and session timeout References: <4E1714D2.6010207@ice-sa.com> <99C8B2929B39C24493377AC7A121E21FAFF984E6DD@USEA-EXCH8.na.uis.unisys.com> <4E176D51.5090703@ice-sa.com> <99C8B2929B39C24493377AC7A121E21FAFF984E86D@USEA-EXCH8.na.uis.unisys.com> <4E19B6E9.4040800@christopherschultz.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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