Thank you all for the input.
I added the system property
org.apache.catalina.session.StandardSession.ACTIVITY_CHECK and set it
to true, and it appears to be preventing the session timeout. That's a
good news. Some one told me that there might be some performance
issues, but I'm not sure how significant they are.
Now, one thing I noticed in the same test 800 MB file (client and
server on the same system) with a session timeout of 30 seconds...
After the Servlet received/stored all the files (which could be up to
5 files in a single upload request), it creates a Bean/List with
status of each file (e.g. file 1 successful, file2 failed because a
file with the same name already exists etc..). Sets this status bean
in request scope, and forwards the request to a JSP.
The call to forward from the Servlet finishes in no time. However, it
takes about minute by the time the browser renders this JSP. While the
browser is waiting for the reply, the session is getting destroyed. My
question is, what is taking so long after the request is forwarded.
The code snippet we use to forward the request is -
request.getRequestDispatcher("/MyJSP.jsp").forward(request,
response);
I've a debug line before this call and after this call, they both get
printed right one after the other with no delay, but the browser does
not get anything back for about a minute. If I upload fairly small
files, the browser gets the response back almost right away. The delay
in receiving the reply on large files is not new (or not caused by the
new additional system property).
Any ideas on what could be going on? Does Tomcat some how feeds (or
tries to) the whole multipart request (after it is consumed by the
Servlet) to the forwarded JSP? I doubt it because, I did not notice
any temp files being created where the request might have been cached.
The memory usage was pretty low during the whole process so the
request is definitely not cached in memory.
Thanks.
Sai Pullabhotla
On Fri, Jul 8, 2011 at 4:09 PM, Caldarale, Charles R
<chuck.caldar...@unisys.com> wrote:
>> From: André Warnier [mailto:a...@ice-sa.com]
>> Subject: Re: Uploading large files and session timeout
>
>> The do this cleanly, the servlet would need to call
>> HttpSession.getMaxInactiveInterval() at the beginning,
>> to save the existing value, then call
>> HttpSession.setMaxInactiveInterval() to set a new one
>> for the duration of the transfer, then process the upload,
>> then at the end call HttpSession.setMaxInactiveInterval()
>> to reset the old value, right ?
>
> Correct, but slightly more complicated due to the previously undisclosed
> possibility of concurrent uploads associated with a single session.
>
>> Since the "session expiration" is determined in function of
>> the MaxInactiveInterval and the lastAccessTime, and since
>> Tomcat has no way to know at the beginning of a request, how
>> long this request will take to process, I would think that the
>> lastAccessTime would be updated *at the end* of a request, not
>> at the beginning.
>
> Tomcat 7 (which is not what the OP is using) has these system properties to
> control session timeout behavior:
>
> StandardHostValve.ACCESS_SESSION
> StandardSession.ACTIVITY_CHECK
> StandardSession.LAST_ACCESS_AT_START
>
> (Determining the actions taken for each property setting is left as an
> exercise for the Tomcat documentation reader.)
>
> Tomcat 6 uses only the ACTIVITY_CHECK property, and session expiration is
> based only on when the most recent request arrived - as required by the spec.
> The properties in Tomcat 7 appear to have been added as workarounds for the
> shortcomings of the spec that you have pointed out.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
